dbt Cloud pricing in 2026: seats, model builds and dbt State

TL;DR. dbt Cloud pricing in 2026 has two meters on the same model. Starter charges $100 per developer seat, includes 15,000 successful models built a month, and last published $0.01 per model above that. dbt State, announced in preview on June 1, 2026 and billed under a rate table effective July 1, charges $0.094 for each table or test it skips, once per day. That's 9.4 times what a build costs above the included 15,000. On a hypothetical 600-model project whose data lands once a day, an hourly job with dbt State costs $5,482 a month on the dbt bill, while the same project on a daily schedule costs $530 and rebuilds each table just as often.

dbt Cloud pricing (dbt Labs now calls the product the dbt platform) used to be one question: how many seats and how many models built. Since July 2026 there's a second meter for the models dbt does not build. A skip costs $0.094 a day per table, a build above the included 15,000 costs $0.01, so a skip pays for itself only through the warehouse compute it saves. The figures below come from dbt's pricing page and billing docs, read November 6, 2026. The project is a worked model; no project ran.

What changed in dbt pricing in 2026: a meter for skipped models

The plans look as they did a year ago. A June 2025 snapshot of the pricing page already lists Developer, Starter, Enterprise and Enterprise+, so the Team plan's rename to Starter isn't a 2026 change. Today's plans:

Three things did change in 2026:

1. The merger closed. Fivetran completed its all-stock merger with dbt Labs on June 1, 2026, announced on October 13, 2025, and released dbt Core v2.0 in alpha under Apache 2.0 the same day.
2. dbt State became a paid add-on. The dbt State docs call it "a new and improved version of state-aware orchestration", announced on June 1, 2026. The dbt Service Consumption Table, effective July 1, 2026, bills it "at a list rate of $0.094 per DATT".
3. dbt Wizard, the AI agent, bills per token at each model provider's rate, after a $100 trial credit. Enterprise accounts get $100 a month of Wizard credits and Enterprise+ $200, per the pricing page.

What we know and what we don't, as of November 6, 2026: until July 2026, dbt's billing docs gave Starter's formula as ($100 x number of developer seats) + ((models built - 15,000) x $0.01). The current Starter billing docs say extra usage "is billed at the rates on our pricing page", and that page shows no per-model rate. This post uses $0.01 as the last published rate. Enterprise rates are negotiated and unpublished.

Since the merger, one company sells two meters for the same dbt project. Fivetran's Transformations for dbt runs a dbt project "with a hosted service", and Fivetran's Service Consumption Table (V.11, effective November 1, 2026) bills its model runs on a falling curve: the first 5,000 a month free, $0.01 each up to 30,000, $0.007 up to 100,000, then $0.002. The ingestion side of that bill is in our Fivetran pricing breakdown.

How dbt State bills a skip: $0.094 per table per day

The dbt State usage docs define a daily active target table (DATT) as a distinct target table on which dbt State performs "a skip, clone, or test reuse" on a given UTC day. Three details decide the bill:

• Tests count. "If stg_customers has not_null and unique tests on its id column, that's three target tables." Tests never count as models built, but they do count as DATT.
• A day is the unit. All reuses of the same table in one day are one DATT. An hourly job that skips a table 23 times pays $0.094, not 23 times that.
• The free allowance is small and temporary. Starter gets 1,000 DATT a month and Enterprise 2,000, "available until" March 31, 2027. Legacy Teams accounts get 1,000 until December 31, 2026. Self-hosted dbt and Developer accounts keep 1,000 a month indefinitely.

On Starter with a card on file, dbt State "keeps running and bills your card for usage past the limit". dbt emails the admin at 80% of the allowance.

So on the dbt bill alone, replacing builds with skips has a break-even. Take a model rebuilt r times a day with t tests, above the included 15,000. Without dbt State it costs r × $0.01 a day. With dbt State rebuilding it once, it costs $0.01 + (1 + t) × $0.094. dbt State saves on the dbt line only above 10.4 runs a day for a model with no tests, and above 29.2 runs a day for a model with two tests. An hourly model with two tests costs $0.24 a day built every hour and $0.292 with dbt State.

Who pays more under the new plans: frequent schedules on data that arrives rarely

Consider a hypothetical team on Starter: five developer seats and one project of 600 models (400 tables or incremental models and 200 views) with two tests each, so 1,200 tests. The source data lands once a day. Builds use a 30-day month and leave out CI builds, which also count.

Models built are models × runs a day × 30. In the dbt State row, each table rebuilds once a day after its data lands. The views never rebuild, because dbt State "reuses it even if new data has arrived upstream" while the view's logic is unchanged. So the 600 models and 1,200 tests are 1,800 DATT a day, 54,000 a month. Less the 1,000 free that's 53,000 × $0.094 = $4,982.

The hourly job with dbt State costs $4,952 a month more than the daily job, for the same table builds a day. Against the plain hourly job it costs $812 more on the dbt line. It avoids 276,000 table builds a month, so it pays for itself overall if each avoided build cost more than $0.0029 of warehouse compute. We did not price the warehouse side, so set your own build costs against that bar. That's dbt's case: its press release says dbt State helps "reduce underlying infrastructure costs by 30% or more", a vendor claim we did not test.

These figures hold for list prices only. Enterprise rates, Committed Use Discounts and whatever replaces the free allowance after March 31, 2027 will change every one of them. CI builds, Semantic Layer queried metrics and dbt Wizard tokens would add to them.

Which teams pay more:

1. Teams that buy dbt State to fix a schedule. If the data lands daily, a daily job removes the same builds for free. dbt State earns its fee where arrival is irregular, or where each source changes on its own clock.
2. Projects with many tests. Every reused test is a DATT, and tests were free under the model meter.
3. Projects with many views. Views "don't store data", in dbt's words, so rebuilding one reruns a create view statement and no transformation. Skipping it with dbt State costs $0.094 a day to save that statement.
4. Everyone on a paid plan after March 31, 2027. The docs don't say what replaces the temporary allowance. In this example the 1,000 free DATT last about half a day.
5. Teams of six or more developers. Starter has five seats. dbt's billing FAQ sends teams that need more to sales for Enterprise.

The counterargument is fair: a model meter made waste visible that a flat seat price never showed, and dbt State turns skipped work into a line on the invoice you can read. Both are true. The bill now shows the cost of a schedule that runs faster than the data arrives; it doesn't fix it.

How many model runs does your project use?

The planning formula is models in each job × runs a day × days, plus one build of every changed model per CI run. dbt's definition counts views, tables and incremental models built in a deployment environment, "even if the overall run later fails". For actuals, the Billing page in Account settings shows the month's estimate. Each project's home page shows models built per month, and the job's Insights tab shows them per job.

To count your own runs outside the UI, sum successful models in the run_results.json artifacts of a month of runs. Each result carries a unique_id and a status:

import glob, json

built = 0
for path in glob.glob("artifacts/2026-10-*/run_results.json"):  # one folder per run
    for r in json.load(open(path))["results"]:
        if r["unique_id"].startswith("model.") and r["status"] == "success":
            built += 1
print(built)

With dbt State on, check how your dbt version reports reused nodes before you trust this count. We did not test that.

Which models can you stop running? Views first, then models nobody reads

1. Take views out of scheduled jobs. dbt's own cost guide suggests --exclude config.materialized:view plus a merge job that runs state:modified+ when code changes. In the example that removes 144,000 builds and $1,440 a month.
2. Match each job to when its data lands. Moving the 600 models from hourly to daily removes $4,140 a month of overage. If you use dbt State, its lag_tolerance (default 45 minutes, per the dbt State configs) sets how long a model waits after new upstream data.
3. Stop models with no reader. A model with no child model, no exposure and no query outside dbt in 90 days is billed every run and read by nobody.

Find the leaf models in manifest.json, whose child_map lists each node's first-order children:

import json

m = json.load(open("target/manifest.json"))
for uid, kids in m["child_map"].items():
    if uid.startswith("model.") and not any(
        k.startswith(("model.", "exposure.", "semantic_model.")) for k in kids
    ):
        print(m["nodes"][uid]["relation_name"])

Then check those relations against 90 days of Snowflake ACCESS_HISTORY, leaving out dbt's own user:

with readers as (
  select upper(o.value:"objectName"::string) as relation, count(*) as reads_90d
  from snowflake.account_usage.access_history h,
       lateral flatten(input => array_cat(h.direct_objects_accessed,
                                          h.base_objects_accessed)) o
  where h.query_start_time > dateadd('day', -90, current_timestamp())
    and h.user_name != 'DBT_PROD'                   -- your dbt deployment user
  group by relation
)
select t.table_catalog || '.' || t.table_schema || '.' || t.table_name as relation
from analytics.information_schema.tables t          -- your dbt target database
left join readers r
  on r.relation = t.table_catalog || '.' || t.table_schema || '.' || t.table_name
where t.table_schema in ('MARTS')                   -- your dbt schemas
  and r.relation is null;

ACCESS_HISTORY needs Enterprise Edition, keeps 365 days and can lag "up to 180 minutes". A relation on both lists is a candidate, not proof: an export, a share or a quarterly report may read it from outside the warehouse. Ask its owner, then drop it or move it to a weekly job. The same reader test applies to the Fivetran tables underneath, as in our data pipeline cost guide.

Leaving the dbt platform for dbt Core removes the seat and model meters, but you then run and pay for the orchestrator, the CI runner and the machine yourself. dbt State still counts DATT there if you turn it on: 1,000 a month are free, and past that you pay $0.094 each only if you set up usage-based billing.

A dbt model's real cost sits in three places: the dbt invoice, the warehouse that runs it, and the people who do or don't read its output. Datapace is building one map of your data estate (databases, warehouses, pipelines and what consumes them) with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. To see the rest of the bill a dbt project sits on, read data warehouse cost.

Sources

1. dbt Labs, Pricing, read November 6, 2026 (plans, seats, included models, Wizard credits), and the June 13, 2025 Wayback Machine capture.
2. dbt docs, Plans and billing, How does dbt pricing work?, Billing FAQs and Optimize costs in dbt, read November 6, 2026.
3. dbt docs source, billing.md at commit 87213c6, July 13, 2026 (the Starter cost formula).
4. dbt docs, dbt State usage, About dbt State and dbt State configurations.
5. dbt Labs, Service Consumption Table, effective July 1, 2026 (DATT rate).
6. Fivetran, Fivetran + dbt Labs Complete Merger, June 1, 2026.
7. Fivetran, Service Consumption Table V.11, effective November 1, 2026, and Transformations for dbt.
8. dbt docs, run_results.json and manifest.json; Snowflake, ACCESS_HISTORY view.