Paradime State

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.

​

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 at the end of the run.

​

Skip, clone, or 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. 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.

​

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

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.

​

Supported warehouses

On any other warehouse, runs build as plain dbt™. On every warehouse, declare a loaded_at_field 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.
• 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