Ultimate dbt Cheat Sheet

dbt seed loads CSV files stored in your seeds/ folder into your data warehouse as tables. Seeds are best for small, static reference datasets. For example,  country codes, territory mappings, or status lookup tables.Seeds are not suitable for large datasets. Run dbt seed to load them, and reference them in models using ref() just like any other model.Note that the CSV files for seeds are part of your dbt project and are committed to git, so you would not use a seed to load data that gets refreshed on a regular basis.

Use the --select or -s flag with the model name: dbt run --select my_model.
You can also target models
* by folder path (dbt run --s models/staging)
* by tag (dbt run --s tag:daily)
* by file path (dbt run --s path/to/some_model.sql)

To preview which models will be selected without running them, use dbt ls --select my_model first.

dbt retry re-executes the last dbt command starting from the point of failure. It reads run_results.json to determine which node failed and picks up from there. This is useful in CI/CD pipelines or long production runs where a transient error caused a mid-run failure and you do not want to rebuild models that already succeeded. Note, the run_results.json of the prior run must be availeble for dbt to know where to resume execution.

The --full-refresh flag forces dbt to drop and recreate incremental models from scratch instead of appending or updating records. Use it when the logic of an incremental model has changed, when the schema has been altered, or when you need to reprocess historical data. Without it, incremental models only process new or updated records since the last run.

The + operator selects upstream or downstream models relative to a target model. Placing + before a model name (e.g., +my_model) selects the model and all its upstream dependencies. Placing it after (e.g., my_model+) selects the model and all downstream dependents. You can use both (e.g., +my_model+) to select everything connected to a model in both directions.

dbt Core is the open-source engine. It gives you full control but requires you to build and manage your own environment ‚ CI/CD, orchestration, secrets management, and infrastructure. dbt Cloud is a hosted SaaS platform from dbt Labs with a managed IDE and scheduler, but it limits flexibility, restricts private cloud deployment, and can be expensive at scale. Datacoves is a managed dbt Core alternative that delivers the usability of dbt Cloud without the trade-offs: it runs in your private cloud, integrates with Airflow, VS Code, and your existing tools, and includes pre-built CI/CD and best-practice guardrails out of the box.

dbt run executes only your SQL models. dbt build does everything: it loads seeds, runs snapshots, executes models, and runs tests, as well as user defined functions(UDFs) in dbt 1.11+. For production pipelines and CI/CD, dbt build is the right choice. Use dbt run during active development when you want to iterate quickly on a single model without triggering the full test suite.

‍

dbt test runs all tests defined in your project but does not execute models. dbt build runs models and immediately tests them after each node in DAG order. If a test fails on an upstream model, downstream models are skipped entirely. For development, dbt test gives you faster feedback on a specific model. For production, dbt build ensures tests gate downstream execution.

The @ operator is like + but more thorough. It selects a model, all its downstream dependents, and all the upstream dependencies of those downstream models. Use it when you need to ensure the complete, self-contained subgraph is rebuilt. For example, when testing a change that affects multiple downstream pipelines and you want every dependency refreshed.

dbt snapshot captures the state of a source table at a point in time and tracks how it changes over time. It is similar to a Type 2 Slowly Changing Dimension (SCD2). It records when a record was added, modified, or removed. Use snapshots when you need historical tracking of records that get updated in place in the source system, such as customer status or order state changes.