What is dbt?
The transformation layer, done right
dbt (Data Build Tool) runs your analytics transformations as versioned, testable SQL in your warehouse. Write a SELECT once; dbt handles the CTE dependencies, ordering, testing, and documentation.
What you will learn
- Explain what dbt does and what it does not do
- Describe a dbt project's core objects: models, sources, seeds, tests
- Understand the compile-and-run loop for a model
What is this?
dbt is a transformation framework that runs inside your warehouse. You write models as SQL SELECT statements; dbt materializes them as tables or views, orders them by dependency, tests them, and documents them — all from a version-controlled project. It does not extract or load, which is exactly the point: it owns the analytics-engineering layer only.
Why do you need it?
- It replaces 'someone's folder of SQL scripts' with tested, reviewed, documented code.
- Dependency resolution means you never manually order a downstream table again.
- The same project builds locally, in CI, and in production — environments stop drifting.
Mental model
Hand-written recipe cards on a fridge
A cookbook with tested recipes in order
dbt turns one-off transformation recipes into a book where each recipe knows which others it needs and was tested before printing.
How it works
- Define sources pointing at raw tables in your warehouse.
- Write models as SELECT statements that read from sources or other models.
- dbt builds the dependency graph, compiles each model to SQL, and runs it in order.
- Tests, docs, and lineage derive from the model code and YAML.
dbt sits between raw loads and the marts analysts consume.
In production
- A growth team rebuilds its nightly retention marts with dbt instead of cron'd scripts.
- Analytics engineers preview model changes in dev before promoting to prod.
- Freshness tests on sources page the owner when the warehouse pipeline stalls.
Best practices
- Keep every transformation as a SELECT — let dbt own materialization.
- Version the project from day one; every model change goes through review.
- Build in dev, promote with tests; never edit production models in place.
Common mistakes
- Writing incremental logic everywhere before the pipeline is even correct.
- Reading raw sources directly in many models instead of extracting sources.
- Assuming dbt fixes a broken upstream load — it transforms what it is given.
Debugging tips
- If a run fails mid-graph, the failing model's SQL compiled but the data broke a test or a join.
- Use dbt compile on one model to inspect the exact SQL that will hit the warehouse.
Interview checkpoint
Quick quiz
A dbt model is written as
dbt belongs to the T of