Optimizing your runs for lower compute, fresher data, and faster iteration with dbt State

Most dbt projects rebuild the same models every run, whether anything changed or not. dbt State changes that.

On every run, dbt State checks warehouse metadata and model SQL, semantically understands whether the result would change, and decides whether to build, skip, clone, or auto-defer to production. The result: 30% average compute savings, fresher data without rebuild waste, and dev cycles that move at the speed of your thinking instead of your scheduler.

In this product breakout, we'll show how dbt State works: how it resolves upstream changes, how freshness SLAs let you rebuild on the business's terms instead of the schedule's, and how auto-cloning from production accelerates local iteration without the cost.

You'll leave knowing how to turn dbt State on, the freshness configurations worth setting first, and the orchestration logic you can finally retire, whether you run on dbt Core, the dbt platform, or somewhere in between.