Optimizing your runs for lower compute, fresher data, and faster iteration with dbt State
dbt State turns freshness rules into model-level code, and it took dbt Labs' own project from 19 scheduled jobs down to 2.
Overview
This session covers how dbt State checks warehouse metadata and model SQL, determines whether a result would change, and decides whether to build, skip, clone, or auto-defer—yielding ~30% average compute savings. See how to do freshness SLA configuration, auto-cloning from production, and activating dbt State everywhere you use dbt.
What you'll take away
- 01
dbt State exists to fix one thing: every run should only build what actually changed, moving freshness logic out of job schedules and into model-level code with a configurable lag_tolerance.
- 02
dbt Labs' own internal project went from 19 separate, often clashing jobs down to 2 after adopting dbt State.
- 03
Early customer results back it up: Fanatics saw 25-30% model reuse and roughly 15% in Snowflake savings on its pilot project after declaring SLAs at the model level.
Session speakers
Reuben McCreanor
dbt LabsIaroslav Zeigerman
Fivetran