dbt Quick Reference

This quick reference collects the CLI commands, YAML configuration keys, and Jinja functions used most often day-to-day in a dbt project, meant as a lookup sheet rather than a tutorial. It assumes familiarity with dbt's core concepts — models, sources, tests, materializations — and focuses purely on exact syntax: what goes in dbt_project.yml versus schema.yml, which flags matter on dbt run, and the handful of Jinja functions (ref, source, config, var) that appear in nearly every model file.

The commands used constantly are dbt run (execute models), dbt test (run data tests), dbt build (run models, tests, seeds, and snapshots together in dependency order), dbt seed (load CSV files from the seeds/ directory), dbt snapshot (execute snapshot definitions for SCD tracking), and dbt docs generate followed by dbt docs serve (build and view the auto-generated documentation site with the full DAG). Selection flags matter just as much as the commands themselves: --select model_name targets one model, --select +model_name includes all upstream parents, --select model_name+ includes all downstream children, --select tag:nightly targets by tag, and --select state:modified+ combined with a stored manifest powers slim CI by running only changed models and their downstream dependents.

dbt_project.yml holds project-wide defaults, most commonly the models: block setting default materialization per directory, e.g. staging models as views and marts as tables. Individual model schema.yml files under models/ carry version: 2, a models: list with name, description, and columns entries, each column optionally carrying tests: (unique, not_null, relationships, accepted_values) and meta: for custom metadata. sources.yml declares external raw tables with database, schema, and tables: entries, each optionally carrying a loaded_at_field and freshness: block that powers dbt source freshness checks, which fail if upstream data hasn't landed recently enough.

The four Jinja functions that appear in nearly every model are {{ ref('model_name') }} (reference another dbt model, builds DAG dependencies), {{ source('source_name', 'table_name') }} (reference a raw source table), {{ config(...) }} (set per-model materialization, tags, or other config inline), and {{ var('var_name', 'default') }} (read a project variable, optionally with a fallback default). Custom macros live in macros/*.sql wrapped in {% macro macro_name(arg1, arg2) %} ... {% endmacro %} and are called the same way as built-in Jinja functions; the dbt_utils package (installed via packages.yml) adds widely used ones like dbt_utils.generate_surrogate_key(), dbt_utils.date_spine(), and dbt_utils.star() that most projects rely on instead of reinventing them.