We built dbt State to stop rebuilding what hadn't changed
Last edited on Sep 16, 2026
Today dbt State is generally available, everywhere you run dbt. This includes your own orchestrator: Airflow, Dagster, GitHub Actions, or a laptop. And as of today, it’s available on Snowflake’s dbt projects. It works on Snowflake, BigQuery, Databricks, and Redshift.
Most dbt jobs run on a schedule. dbt State makes them run on change instead. On every run, it reads your model SQL and your warehouse metadata, works out whether a model's result would be different, and then builds, skips, clones, or defers each node accordingly. There's no selection syntax to write, no manifest scripts, and no custom orchestration to maintain
We built it on a straightforward idea: an enormous amount of redundant work happens in data pipelines, and reusing what hasn't changed would save teams hours of run time and warehouse compute. That has held true.
“Since rolling out dbt State, we’ve reduced costs by 59% on scheduled jobs in the dbt platform running on a Snowflake adaptive warehouse. We’ve reused over 700k models instead of rebuilding, which reduced query run time by two weeks over a 60 day period.” — Chris Shepherd, Principal Data Engineer, RxBenefits
On average, more than 22 million models are built on dbt every single day. Most of the time the upstream data hasn't refreshed, so thousands of models rebuild to produce a result identical to the run before. Early adopters have averaged 15-30% compute savings by stopping that. Simply turning it on nets some benefits, but the bigger jump in compute efficiency happens when teams apply tuned configurations, or move to an adaptive warehouse on Snowflake. More on that below.
The savings are real, and they're not what teams are talking about
Compute savings are the easiest thing to measure, which is why they're usually the reason you turn dbt State on. They show up on the next bill, and they're what gets the project approved.
But when we went back to the teams who have been running dbt State in production and development for weeks and asked what changed, almost nobody led with the number.
"dbt State created a paradigm shift in how we work. With capacity freed up, freshness codified, and simpler, yet smarter orchestration, we can focus on initiatives that add value to our business. And that's on top of the 25% savings on both job run time and BigQuery compute costs." — Gordon Curzon, Head of Analytics Engineering and Data Modeling, Virgin Media O2
Orchestration stops being a scheduling problem
Before dbt State, the way to hit a freshness SLA is to build a job for it. Then another job, on a different schedule, for the part of the DAG with different requirements. Then tags to trigger the right subsets, selectors to narrow them, and source freshness gating layered on top to stop jobs firing when nothing has landed. It works, but it also becomes brittle over time.
dbt State changes moves the freshness from the job schedule to the model. Instead of a job deciding what runs, every model carries its own freshness requirement in code, a lag_tolerance that says how stale a model is allowed to be. Then dbt State decides, per model, per run, whether that requirement is met.
Instead of asking which job a model belongs to, you ask how fresh it needs to be. That's a question an analytics engineer can answer, in a pull request, with review.
At Custom Ink, a four-person analytics engineering team supports around 25 analysts, data scientists, and machine learning engineers across a project of more than 1,000 models. Consolidating that into a single deployment is the part they keep coming back to.
"We've been able to simplify our previous setup down to one run, which is amazing, because it's a very clean deployment. Everybody knows what's going to run. There's no confusion." — Brett Petersen, Director of Data and Metrics, Custom Ink
Development is where you notice it every day
The second thing we heard is that dbt State changed development just as much as it changed deployment.
In dev, the old ritual is familiar to anyone who has worked in a large project. You want to edit one model in the middle of a long lineage. So you clone production into your dev schema, or you write a macro to do it, or you remember to turn on deferral, or you skip all of that, rebuild the upstream chain, and wait. As best as you can, you track how stale your copy has become.
dbt State does the cloning and reuse automatically. You build what you're working on, and the rest is reused.
"Now you just dbt build --select what you're working on. dbt compares against prod state, reuses every fresh upstream at zero compute, and rebuilds only your change. The whole chain resolves in seconds. No clone command, no waiting, no dev-environment ritual, the state tracking you used to do in your head is now the tool's job. It saves so much development time." — Mykkel Rydal, Lead Data Engineer, Joe & The Juice
At Joe & The Juice, iteration on a core sales fact table of 400M+ rows used to take 15-25 minutes a cycle, and --full-refresh was blocked in code because it was too expensive to allow. Setup before new dev work went from 15-25 minutes to zero.
The guardrails move into the infrastructure
For years, the safety net in dev has been knowledge. Nothing technically stops a dbt build from kicking off an entire pipeline. What stops it is a developer knowing the right selection syntax, which means the guardrail is only as good as the least experienced person running the command. It becomes untenable and harder to scale as development work becomes evermore agentic.
dbt State is a structural guardrail rather than a manually enforced one. Codified freshness rules and automatic reuse constrain what any run can cost, regardless of who or which AI agent issued it.
"With dbt State doing the cloning and reuse automatically, the guardrails are just in the infrastructure now, whether it's an analyst or an agent doing the work." — Brett Petersen, Director of Data and Metrics, Custom Ink
Custom Ink leans heavily on AI-assisted development, as many teams do these days, and one clean job flow is part of what makes that workable. It’s consistent DAG behavior at scale.
What dbt State GA means
dbt State is out of preview and generally available. Setup is turning it on. Run a job with dbt State enabled twice and see No-Op (no operation) show up over and over in your logs. Declare freshness SLAs or other configurations with precise controls: lag_tolerance, require_fresh_data_from, compare_unrendered_code, and more. Use dbt state explain to see why any node was built, skipped, cloned, or deferred. Make sure the rest of the data team turns on dbt State in local development so they can iterate faster and lower the cognitive overhead it takes to minimize risk of costly or potentially breaking builds.
We worked with Snowflake to bring dbt State’s intelligent reuse to Snowflake dbt Projects, so as of today, those teams can skip unchanged models without moving where they work.
dbt State on platform includes Cost Insights and now has a richer explain experience for more insight into how to optimize and prove ROI. It also manages concurrent builds so two jobs don't clash on the same model at the same time.
Pricing is consumption-based and tied to reuse rather than builds. You pay for daily active target tables (DATT), so each distinct model or test that dbt State skips, clones, or reuses on a given day. Every reuse after the first within the same day is free. Price is independent of table size and compute, so running jobs more often doesn't increase what you pay. In fact, running more often tends to save more. And every user gets a 30-day free trial. Custom pricing is available for upfront commits.
See the docs to get started today.
Get started in dbt
Join the analytics engineers building data infrastructure that actually scales.
Install dbt Wizard CLI
Get started with an agent purpose-built for analytics engineering. It knows which tool to call, which context to pull, and checks its own work before surfacing anything to you.
