How dbt State actually works to save your compute costs
When building a dbt project, you start with the simplest strategy and only add complexity when you need more speed or reduced cost. At a model-by-model level, this is the view → table → incremental materialization pattern. At a project-wide level, optimizations used to require a lot more complexity - rebuilding only the relevant parts of a project meant you spent a lot of mental energy chaining together selectors like state:modified, source_status:fresher, or config.materialized:view and ensuring fresh JSON artifacts were distributed across your organization.
dbt State provides more speed, reduced cost, and less complexity all in one. It works wherever you do: dbt Core or Fusion, locally or on any orchestrator you choose. Since it's backed by a new paid service (with a 30 day free trial), you don't need to adopt the whole dbt platform to get these savings. dbt State supersedes state-aware orchestration, which required a dbt platform subscription and moving to Fusion.
The most technically interesting part of this is the query normalization process1 which means running the new dbt lint command doesn't instantly sign you up for a full rebuild. But before getting into the depths of syntax trees, let's recap what dbt State actually does for an end user.
The basic dbt State workflow
When dbt runs, it will check with the dbt State server whether a model:
- already exists in the target schema and can be reused
- already exists in another schema and can be reused, or
- needs to be built from scratch.