> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Paradime State
> Paradime State skips, clones, or builds each dbt™ node based on whether its code or upstream data changed, so every run builds only what changed.
Paradime State makes `dbt run` and `dbt build` state-aware. Before it builds anything, it compares each model, seed, snapshot, and test (each node) with its last successful build. If neither the node's code nor its upstream data has changed, the node is skipped. Skipped nodes cost no warehouse compute, so a run that used to rebuild your whole project builds only what changed.
Paradime State runs on dbt™ `2.0-latest`, and nothing in your project needs to change to start using it. To turn it on, see [Turn on Paradime State](/guides/paradime-state/turn-on-paradime-state).
## How a run decides
Every state-aware `dbt run` or `dbt build` goes through four steps:
1. **Compile.** dbt™ compiles the project, so Paradime State has each node's SQL and configuration.
2. **Check the warehouse.** In the background, Paradime State reads when each table the run depends on last changed, from warehouse metadata or from a source's `loaded_at_field`.
3. **Decide.** Each node is compared with its last successful build and gets one of three outcomes: skip, clone, or build.
4. **Build and record.** Only the nodes that need it are built. Paradime State records the new baseline and prints a [summary](/guides/paradime-state/read-a-run) at the end of the run.
## Skip, clone, or build
| Outcome | When | Warehouse cost |
| - | - | - |
| **Skip** | The node's logic is unchanged, and its upstream data is no more than its `lag_tolerance` (45 minutes by default) newer than the data it was last built from. | None |
| **Clone** | The node is a table, and a Bolt schedule has already built identical logic from fresh data in another schema. Paradime State copies that table instead of rebuilding it. | A clone instead of a build |
| **Build** | Anything else: the first run, a code or configuration change, new upstream data, or an upstream node that builds or is cloned in the same run. | A normal build |
A node's logic is its compiled SQL, compared in a normalized form so that whitespace and formatting don't count, together with its materialization and the configurations that change what gets built. See [What counts as a change](/guides/paradime-state/configuration-reference#what-counts-as-a-change).
When a node builds or is cloned, every node downstream of it builds too, in the same run.
### What always builds
Some nodes can't be judged safely, so Paradime State builds them on every run:
* **Incremental models**, **Python models**, and models with a **custom materialization**.
* Models that `select *` directly from a `ref()` or `source()`. Their SQL doesn't change when the upstream gains a column, so Paradime State can't tell whether the result would differ. A `select *` from a CTE is fine.
Views work differently. A view holds no data, so it's reused whenever its SQL is unchanged, even after new data arrives upstream. The tables that read from the view rebuild when the data behind it changes.
Only tables are cloned. In development, incremental models and snapshots can instead be copied from production before they build, with [`pre_clone`](/guides/paradime-state/configuration-reference#state-config).
### Tests, seeds, and snapshots in `dbt build`
* **Data tests** skip when the test and the data it tests are unchanged, and their previous result is replayed. A replayed failure still fails the run.
* A model whose test failed is rebuilt on the next run, so the test runs again.
* **Seeds** skip when the CSV file and its load settings are unchanged.
* **Snapshots** skip when their SQL, configuration, and upstream data are unchanged. Any new upstream data runs them, whatever their `lag_tolerance`.
## Where it runs
| Where | State-aware |
| - | - |
| [Bolt](/products/bolt/index) schedules, including Turbo CI, deferred runs, and retries | Yes |
| The [Code IDE terminal](/products/code-ide/run-and-preview/terminal), including commands DinoAI runs there | Yes |
| DinoAI background agent sessions | No, they run plain dbt™ |
Only `dbt run` and `dbt build` are state-aware. Every other command, including `dbt seed`, `dbt test`, and `dbt snapshot` on their own, runs exactly as it would without Paradime State.
Selectors that compare against a previous run's manifest, such as `state:modified+`, don't work while Paradime State is on. Keep Paradime State off for schedules that use them, typically Turbo CI and continuous deployment. See [Schedules that select with `state:` methods](/guides/paradime-state/troubleshooting#schedules-that-select-with-state-methods-build-nothing).
## Supported warehouses
| Warehouse | How new data is detected | Clones |
| - | - | - |
| Snowflake | Table metadata | Yes |
| BigQuery | Table metadata | Yes |
| Databricks | Table metadata | Yes |
| Redshift | Table metadata | Yes |
| DuckDB and MotherDuck | A `loaded_at_field` on each source (required) | No |
On any other warehouse, runs build as plain dbt™. On every warehouse, declare a [`loaded_at_field`](/guides/paradime-state/configuration-reference#source-freshness) on sources whose table metadata doesn't change when data lands, such as views and external tables.
## If the state service is unavailable
Runs don't fail because Paradime State is unavailable. If it can't reach its service, the rest of the run builds normally, and a `paradime-state:` notice in the log says why. The next run uses Paradime State again.
## Coming from dbt™ State
Paradime State reads the same `state` configurations as dbt™ State (`lag_tolerance`, `require_fresh_data_from`, `pre_clone`, and `evaluate_volatile_sql`), so a project already configured for dbt™ State carries over. Two differences:
* Set `compare_unrendered_code` under `meta`, not `state`. See [`compare_unrendered_code`](/guides/paradime-state/configuration-reference#compare_unrendered_code).
* The older `freshness.build_after` settings from dbt™ state-aware orchestration aren't read. Use `lag_tolerance` and `require_fresh_data_from` instead.
## Next steps
Switch to dbt™ 2.0 and set one environment variable for Bolt, the Code IDE, or both.
Every setting that changes when nodes rebuild.
What the summary at the end of each run tells you.
Fixes for missing summaries, unexpected rebuilds, and missed data.
## Related topics
- [Troubleshoot Paradime State](/guides/paradime-state/troubleshooting.md)
- [Turn on Paradime State](/guides/paradime-state/turn-on-paradime-state.md)
- [Paradime State configuration reference](/guides/paradime-state/configuration-reference.md)
- [Read a Paradime State run](/guides/paradime-state/read-a-run.md)
- [Paradime State: build only what changed](/changelog/2026-09-28/paradime-state.md)