Transform raw warehouse data into trusted, tested, documented models — all in SQL, version-controlled and run in the warehouse. What dbt is and where it fits in ELT, models and materializations, ref/source and the DAG, testing and docs, incremental models and snapshots for history, then deploying with dbt build in CI.
Before you start
dbt is SQL plus software engineering — comfort with SQL (the PostgreSQL course) and warehouse modeling (the Data Modeling & Warehousing course) will make it click faster.
What Is dbt?
dbt is the T in ELT — it turns raw warehouse data into modeled, tested, documented tables using just SQL and software engineering practices. Learn where it fits and set up your first project.
Models & Materializations
A materialization decides how dbt builds a model in the warehouse — as a view, a table, ephemeral CTE, or incrementally. Choosing the right one balances freshness, speed, and cost.
Sources, ref() & the DAG
ref() and source() are what make dbt more than a pile of SQL files — they declare dependencies so dbt builds models in the correct order and draws the lineage graph automatically.
Testing & Documentation
dbt tests are assertions about your data that run in the warehouse and fail the build when broken — catching bad data before dashboards do. Plus auto-generated docs and a lineage graph.
Incremental Models & Snapshots
Rebuilding a billion-row table every run is wasteful. Incremental models process only new rows; snapshots capture how records change over time — dbt’s built-in Slowly Changing Dimension Type 2.
Deploying dbt in CI
Take dbt from your laptop to production — environments and profiles, scheduling with an orchestrator, and a CI check that builds and tests only the models a pull request changed.