What You’ll Master Here
dbt does not transform your data. It turns a folder of SQL files into a dependency graph, works out the order, hands the SQL to your warehouse, and then checks the result — which is a different job, and the reason dbt never asks you to rewrite your queries.
Nearly every analytics team arrives at dbt the same way: not because someone read a comparison of transformation frameworks, but because a folder of SQL files stopped being something one person could hold in their head.
This chapter does not open a code editor. Its job is to make you able to answer one question precisely — what does dbt actually do, and what does it deliberately refuse to do? — because every chapter after this is a detail of that answer. Step through the three moves below before reading on.
dbt does not transform your data. It turns a folder of SQL files into a dependency graph, works out the order, hands the SQL to your warehouse, and then checks the result — which is a different job, and the reason dbt never asks you to rewrite your queries.
Engineers who learn dbt as a list of features end up with a project that is a folder of SQL scripts with extra ceremony: no staging layer, models that select from hard-coded table names, tests only on primary keys, and a lineage graph nobody trusts. Engineers who learn the problem first write projects that a new joiner can change in week one. That difference is visible in a code review within about two minutes.
- Analytics engineering
- The discipline of applying software-engineering practice — version control, testing, code review, modularity, CI — to the transformation layer of a data platform. dbt is the tool that made it practical.
- Model
- A single .sql file containing one SELECT statement. dbt wraps it in the DDL needed to persist the result as a view or table. One file, one model, one object in the warehouse.
- DAG
- Directed acyclic graph — the shape of your project. Directed because data flows one way; acyclic because a model must not be able to depend on itself, however indirectly.
- Warehouse
- The database that actually stores and processes the data: Snowflake, BigQuery, Databricks, Redshift, Postgres, DuckDB. dbt sends it SQL and reads back the outcome. It never touches a row itself.
Learning dbt as syntax — `ref`, `config`, `materialized` — before understanding what problem each one solves. You end up with a project that compiles and runs but reproduces every failure of the folder it replaced: no layering, duplicated logic, and a lineage graph that is technically correct and practically useless.
Be able to state in one sentence what dbt does that plain SQL scripts do not. If you cannot, no amount of macro trivia will cover for it.
When you meet a new dbt feature, ask which failure it exists to prevent. A feature with no failure attached is usually a feature you do not need yet.
Treat “the run went green” and “the numbers are right” as two separate claims. Most of the expensive incidents in analytics live in the gap between them.
Your SQL was never the problem. What decays as a team grows is everything around the SQL — the order, the freshness, the definitions, the ability to change one thing without breaking another. dbt is a tool for that surrounding layer, which is exactly why adopting it does not require rewriting your queries.
You are not here to learn a SQL runner with extra syntax. You are here to learn how a folder of queries becomes a system somebody else can safely change.