dbt Cheat Sheet

dbt run builds models only. dbt test runs the unit tests defined on SQL models and the data tests defined on models and sources. Data tests on snapshots and seeds run too. dbt build does both in DAG order and also handles seeds and snapshots, so a seed loads before the model that reads it and a model is tested before its children are built.

The ordering has a consequence that run then test does not have. In dbt build, a failing test on an upstream resource blocks the resources downstream of it, and they're skipped entirely. To let a test report without blocking, set its severity to warn. Run as 2 commands, dbt run would already have built every child on the bad data before dbt test found the problem.

To split the tests by kind, use the test_type selector. dbt test --select test_type:data or dbt test --select test_type:unit makes the first split, and test_type:singular or test_type:generic divides the data tests by how they are defined. The --empty flag on run and build limits refs and sources to zero rows. dbt still executes the model SQL against the warehouse, so it validates the project without reading the input data.

dbt run --full-refresh (short form -f) treats incremental models as table models, and is_incremental() returns false for every model during that run. Use it after an incremental model's schema or logic changes. How incremental models decide which rows to process is covered on its own page.

A selector can name a resource or use a method before a colon. The documented methods include tag: and config., the latter followed by a config such as materialized. Next are source: and package:, then fqn: and group:, with access: last. The list continues with exposure: and metric:, then test_type: and test_name:. After those come unit_test: and state:, and the last two are result: and version:. The path: and file: methods apply to dbt v1.11 and later, as do the resource_type: method and source_status:.

2 methods suit pipeline work. source:snowplow+ selects the models that read from a source, and +exposure:weekly_kpis selects everything that feeds an exposure, so you can rebuild just what a dashboard depends on. test_name:unique selects every test of the generic unique test across the project.

dbt list (or dbt ls) prints what a selector would pick without running anything, and it does not connect to the database. Check a complicated selector there first with dbt ls --select "tag:nightly" --resource-type test. Set --output to json or name to pick the format; path or selector work as well. The node selection syntax reference has the full method list.

The state: method compares the project with a previous manifest, so dbt run --select "state:modified" --state path/to/artifacts builds only the nodes that differ from the artifacts in that directory. Add the plus for the children, as in state:modified+. The result: method does the same with a prior run's outcomes, so dbt run --select "result:error" --state path/to/artifacts picks the resources that failed last time.

dbt retry is the shorter route for the common case. It reads run_results.json from the last invocation and re-executes from the point of failure, so after you fix a failed customers model it rebuilds that model and not its upstream dependencies. It needs dbt v1.6 or later, and the docs list the commands it covers. The list opens with build and compile, then clone and docs generate, then seed and snapshot, test and run, with run-operation last.

Its limits are plain. If the previous command succeeded, retry finishes as a no operation. If the failure came before any node ran, such as a bad warehouse connection, no nodes were recorded and retry runs nothing, so you rerun the full command. Retrying without fixing the cause yields the same failure.

dbt clone --state path/to/artifacts copies selected models from that state into the target schema. Where the platform supports zero-copy clones of tables, which Snowflake and Databricks do and BigQuery does too, dbt creates a clone, and otherwise it creates a view that selects from the source object. By default it does not recreate relations that already exist, and --full-refresh overrides that. It needs dbt v1.6 or later.

dbt source freshness checks whether sources meet the staleness thresholds in their config. It writes target/sources.json, and when a table is stale it reports a warning or an error and exits with a nonzero exit code, which is what a scheduler needs to see. Select part of the set with --select "source:snowplow.event". In the YAML, the freshness block moved under config in dbt v1.9 and loaded_at_field in v1.10.

dbt seed loads the CSV files in seed-paths as tables and suits small reference data such as country codes. --full-refresh forces a full reload when the file's columns or types change. dbt seed --empty, available in dbt v1.12 and later, creates the tables with the right schema and no rows. That lets downstream models run in development or CI, and unit tests too.

dbt snapshot records changes to a source over time as a type-2 slowly changing dimension, so run it on a schedule. Snapshots ignore --full-refresh, which means dbt build --full-refresh runs a snapshot as normal and keeps its history.

dbt run-operation calls a macro by name, with arguments as a YAML string: dbt run-operation clean_stale_models --args '{days: 7, dry_run: True}'. It is the route for grants and other maintenance SQL that is not a model.

dbt deps installs the packages in packages.yml and writes package-lock.yml. While packages.yml is unchanged, it installs the locked versions, so commit the lock file. dbt deps --upgrade forces an update of every package and can change your builds, --lock updates the lock file without installing, and --add-package dbt-labs/dbt_utils@1.0.0 adds an entry.

dbt debug is a command, not the --debug flag, which only raises log verbosity. It checks the connection, dbt_project.yml, the system environment, required dependencies such as git, and the adapter. dbt debug --connection tests only the connection, and --config-dir prints how to reach the folder where dbt looks for profiles.yml.

dbt compile renders each model's SQL into target/compiled/ without running it, which is the fastest way to read what a Jinja macro produced. dbt show --select my_model runs the compiled query and prints the first 5 rows, and the --limit flag wraps the query in a SQL limit, so the warehouse returns only that many rows. dbt clean deletes the artifacts of the project, and dbt parse parses the project and writes timing information.

Interviewers rarely ask for flag names. They ask what you would run in a situation: a nightly job that failed on model 14 of 40, a pull request that should build only the changed models, an incremental model whose logic changed. The answers on this page map straight onto them. dbt retry or result:error come first. state:modified+ and --full-refresh follow. The dbt interview questions cover dbt models and tests as well as sources in that style.

Most dbt work is SQL, so the other half of preparation is the SQL itself. The SQL interview questions and the SQL practice problems cover the queries your models contain, and the data engineer interview prep guide shows where dbt fits in the loop.