dbt model
A single SQL SELECT statement in a dbt project that defines one transformed table or view. dbt handles the DDL, dependencies, and materialization so you just write the SELECT.
In dbt, a model is just a `.sql` file containing one SELECT statement. You never write CREATE TABLE — dbt wraps your SELECT in the right DDL and builds it as a view or table according to the model's materialization. References between models use the `ref()` function, which lets dbt infer the dependency graph and build things in the right order.
Models are organized in layers: staging models clean and rename raw source data one-to-one; intermediate models do the heavier joins and logic; mart models are the final, business-facing facts and dimensions. This layering keeps logic modular and testable.
Because every model is code, you get version control, code review, automated testing, and documentation for free — which is the whole point of analytics engineering.
Models + `ref()` are what turn a tangle of ad-hoc queries into a dependency-aware, testable pipeline. dbt can build everything in the right order, test it, and document it because models declare their relationships.
This is the day-to-day surface of the analytics engineering job — most of your time is spent writing, reviewing, and testing dbt models.
- Hard-coding table names instead of using `ref()`/`source()`, which breaks dbt's dependency graph and lineage.
- Putting business logic in staging models instead of keeping staging one-to-one with sources.
- Skipping tests, so a model 'runs' but silently returns wrong results.
- Do I write CREATE TABLE in dbt?
- No. You write a SELECT; dbt wraps it in the correct DDL based on the model's materialization (view, table, incremental, or ephemeral).
Go deeper in the dbt for Analytics Engineers hub.
Learn this by building, not memorizing.
Definitions get you the vocabulary. The platform gets you the skill — graded exercises, real projects, and a portfolio capstone.