using-dbt-state
Installation
SKILL.md
Using dbt State
dbt State is a server-backed reuse mechanism. It should not be conflated with dbt's state:modified selector or --state deferral.
Before building each selected node, dbt asks the dbt State server whether the object can be skipped (reuse from the target schema), cloned (reuse from another schema), or must be built. It is the successor to State-Aware Orchestration, but works in dbt Core, in development, and in CI — not just Fusion in production.
dbt State is a paid product, but it does not require a dbt platform (fka dbt Cloud) subscription.
Common Misconceptions
| Misconception | Reality |
|---|---|
"dbt State is just state:modified / --state" |
No. state:modified hashes file contents against a manifest you manage and rebuilds state:modified+ (all descendants). dbt State manages state automatically on a server, parses SQL into a syntax tree and compares semantic hashes, considers upstream data freshness, and rebuilds a descendant only if it actually depends on the change (not the whole + subtree). |
| "It's Fusion-only / production-only" | Works in dbt Core, the dbt platform, and Fusion, across dev, CI, and production, with any orchestrator. |
| "dbt Core users can't use it" | They can. dbt Core 1.7–1.11 require pip install dbt-state. It's baked into dbt Core 1.12 / v2.0 and Fusion. |
| "It's free / it's local" | It calls the dbt State server and requires authentication via a dbt platform account or a standalone dbt State account (app.state.dbt.com). Reuse is metered in DATTs — daily active target tables (see Billing below). |
| "It sends my data to dbt Labs" | It sends last-modified timestamps and SQL text. The SQL is hashed then discarded — dbt Labs cannot read query contents after hashing, and can never access raw data. |