Build what’s changed, skip what hasn’t.

dbt State builds only what has changed. Simplify orchestration, iterate faster in governed dev environments, and cut warehouse compute by 15-30%. Locally or in the cloud.

Why dbt State

Stop rebuilding. Start saving.

Whether you're orchestrating in the dbt platform, running dbt locally, or using an external orchestrator, dbt State makes every run smarter: less compute, simpler orchestration, and faster iteration.

Simplify orchestration

Apply freshness on the model in code, not in the scheduler. Run as often as the business needs. No custom workflows, no manual orchestration.

Develop faster with guardrails

Start building in seconds without any complex setup rituals. Iterate freely and faster without fear of expensive mistakes or breaking changes.

Optimize performance

Reduce warehouse compute by 15-30% on average by only building models when upstream data or code has actually changed. Stop paying to rebuild what hasn't.

Virgin Media O2

dbt State has been a paradigm shift for how we work. With freshness codified, simpler orchestration, and ultimately, freed-up developer capacity, we focus more time on initiatives that add value to our business. And that’s on top of the 25% savings on both job run time and warehouse compute costs.

Gordon Curzon Head of Analytics Engineering at Virgin Media O2

How it works

Intelligence built into every run.

On every run, dbt State checks your metadata and model SQL to see what’s changed. When upstream data or code has changed, it builds the model. Otherwise, it skips the build by:

  • Reusing existing state — zero compute, zero risk
  • Cloning existing state with minimal compute cost
  • Auto-deferring (in development) to production state

This works for full models, incremental models, snapshots, seeds, and tests.

In production

Simpler orchestration, fresher data, more efficient runs.

Eliminate hours spent maintaining custom workflows and manual orchestration. Just turn dbt State on, configure freshness, and run your jobs as often as you need. That means fresher data, less complexity, and meaningful warehouse savings without changing how you work.

Tuned configurations. Declare freshness and dependency rules directly in your project code. Set a max staleness window via lag_tolerance so models rebuild only when they're due — not every run. Move orchestration logic from imperative scheduling into declarative, version-controlled configurations.

DAG graphic showing tuned configs, lag_tolerance and require_fresh_data_from
Image of a DAG explaining that only the model the developer would work on is getting built.
In development

Iterate faster in governed dev environments.

Not only does dbt State skip and clone models in development, but it can auto-defer to production state, so analytics engineers can start building immediately — no manual overhead and no fear of costly mistakes.

Auto-clone from prod and auto-defer let you start building in seconds. Only run the part of the DAG you’re working on. No cloning macros, no staleness bookkeeping. No selection-syntax expertise needed; dbt State is a structural guardrail against runaway dev cost, no matter who, or which AI agent, runs the command.

Customer proof

Trusted by data teams

  • Chris Shephard

    Since rolling out dbt State, we’ve reduced warehouse costs by 59% on scheduled jobs in dbt platform. That’s $8,173.23 in the first 60 days alone on top of a Snowflake adaptive warehouse. We’ve reused 716k models instead of rebuilding, which reduced query run time a total of 14 days, 11 hours, and 15 minutes over the same period.

    Chris Shephard, Principal Data Engineer, RxBenefits

  • Parag Shah

    Before dbt State, every job rebuilt every model in the lineage. Every. Single. Time. Now, with dbt State, dbt checks if source data changed. If it didnt, the model is skipped. For us, that resulted in a 9% compute reduction, 35% fewer models built, and a 15% reduction in Snowflake costs.

    Parag Shah, VP of Data, CarGurus

  • Alvin Chai

    Declaring SLAs at the model level and letting it decide what actually needs to run has already delivered 25-30% model reuse and roughly 15% in Snowflake savings on our pilot project.

    Alvin Chai, Senior Analytics Engineer, Fanatics

  • Obie Insurance

    Were saving at least 30% on compute costs, just from reusing models with dbt State

    Tyson Doberneck, Senior Data Engineer

    Read Obie Insurance's story
    Pricing

    Reuse more, save more.

    dbt State pricing is usage-based. You pay based on the benefit from model reuse. dbt State cost is measured using Daily Active Target Tables. Daily active target tables (DATT) are measured as the number of distinct target tables for which dbt State performs a unique skip or clone, and unique test reuse operations on a given calendar day.

    Visit the pricing page to learn more.

    Frequently asked questions

    Stop rebuilding unchanged models. Start saving today.

    Get started in minutes — whether you run dbt locally or in the dbt platform.