Disclaimer: dbt has a lot of power under the hood- this guide just covers what we’ve learned about and utilized this week in data engineering!
dbt deps
- Installs all required packages listed in your packages.yml.
- Always run this if you’ve updated your packages.yml.
Ex. When we started using macros from dbt-utils or packages from our shared repo, this command pulled them in so we could use them across models.
dbt run
- Executes all models in your dbt project (according to dependency order).
- It doesn’t run tests or snapshots- just models.
Ex. We used this after building staging and intermediate models—it created the views and tables in our Snowflake schema.
dbt run -s <model> or dbt --select <model>
- Runs a specific model (or multiple, depending on your selector).
Ex. You’re working on orders_with_detail and don’t want to run the whole project- just: dbt run -s orders_with_detail
dbt docs generate
- Builds interactive documentation for your dbt project.
- This gives you a visual map of your models, relationships, sources, descriptions, tests, and more.
- Run dbt docs serve after to view it locally.
dbt test -s <model>
- Runs tests on the specified model (like unique, not_null, etc).
- Runs only the tests tied to that model.
Ex. dbt test -s orders_with_detail
dbt test -s orders_with_detail --store-failures
- Runs the tests and stores any failures in a special schema (usually dbt_test__audit).
- This helps us inspect why something failed- great for debugging duplicate IDs or missing values.
dbt build -s <model>
- Combines run + test + snapshot + seed into one command.
Ex. We started using dbt build when we wanted to create our model and test it right after- no extra step.
dbt build --select source_status:fresher+
- Only builds models where the upstream source is fresh (and everything downstream).
- Requires source freshness checks to be set up.
Ex. This is perfect when you’re working with slowly changing or batch-loaded data and only want to run what’s changed.
dbt list --select source_status:fresher+
- Lists the models that would be run by the command above- but doesn't run them.
- We used this to preview what would change before kicking off a full build.
dbt build --select state:modified+
- Builds only models that have changed (and their downstream dependencies).
- Requires a state comparison, often in CI or with the --state flag in dbt Cloud.
Ex. You updated a stg_orders.sql file and want to rebuild everything that depends on it- this targets just those changes, saving time.
dbt clone --select state:modified+, config.materialized:incremental
This is a more advanced example using selectors and filters together:
- state:modified+ = models that changed, plus downstream
- config.materialized:incremental = only models that are incremental
We used this when testing performance changes only on incremental models.