dbt (data build tool)
The data transformation tool that brings software engineering discipline — version control, testing, documentation — to SQL-based data modelling.
What it is
About dbt (data build tool)
dbt (data build tool) is the layer in the modern data stack that sits between raw data in a warehouse and clean, reliable data models that analysts can query. A data analyst or analytics engineer uses dbt to write SQL `SELECT` statements — one file per model — and dbt handles the rest: materialising the query results as a table or view in the warehouse, managing dependencies between models (so downstream models only run after their upstream dependencies have completed), running data tests, and generating documentation. A dbt project typically contains dozens or hundreds of models organised into staging (raw data lightly cleaned), intermediate (transformations and joins), and mart (business-ready tables optimised for reporting) layers. The key insight dbt brings is that data transformation is software engineering, not just SQL writing. Every dbt model lives in a Git repository — changes are reviewed in pull requests, transformations have version history, and the data lineage is visible in an auto-generated dependency graph. dbt tests (`not_null`, `unique`, `accepted_values`, `relationships`) are data contract assertions that run automatically on each deployment — a test failure blocks the pipeline and prevents broken data from reaching downstream dashboards. dbt Cloud provides a managed environment for scheduling, running, and monitoring dbt jobs; dbt Core is the open-source CLI that runs in any environment. For Data Analysts moving into analytics engineering roles, dbt is the skill that bridges SQL proficiency and software engineering practice.
What you can do with it
Capabilities
Write a dbt staging model that reads from a raw events table, renames columns to a consistent snake_case convention, casts data types, and filters out test events — materialised as a view that downstream models can build on without touching the raw layer
Build a dbt mart model joining the staging orders, customers, and products models, add a `not_null` test on the order ID column and a `relationships` test verifying every customer ID references a valid customer — and confirm all tests pass on a `dbt test` run
Run `dbt docs generate` and `dbt docs serve` to open the auto-generated documentation site, navigate the lineage graph to see which upstream tables feed a specific mart model, and add a model description and column-level comments to improve the documentation for the team
Set up a dbt Cloud job that runs every morning at 6am, sends a Slack notification on failure, and stores a manifest artefact so the next job run only re-tests models whose dependencies have changed — using dbt's slim CI feature
Refactor a 300-line SQL query that joins seven tables into four separate dbt models in the staging and intermediate layers, use `{{ ref() }}` to declare the dependencies explicitly, and verify the lineage graph updates to show the correct dependency chain
How to learn it
Learning Resources
dbt's official Learn at courses.getdbt.com — free structured courses including "dbt Fundamentals" (4 hours) and "Jinja, Macros, Packages" (2 hours); the best starting point and uses dbt Cloud's free developer environment
dbt documentation at docs.getdbt.com — the "Best Practices" guide and the "How we structure our dbt projects" page document the standard model layer conventions used across the industry
dbt Slack community (getdbt.com/community) — one of the most active data communities; the #help channel answers most dbt questions within hours
"The dbt Viewpoint" (docs.getdbt.com/community/resources/viewpoint) — the foundational philosophy document explaining why dbt was built; reading it before the tutorials gives the framework for every design decision you'll make in a dbt project
Pro Tip
Write the `schema.yml` documentation and tests at the same time as the model — not afterward as a cleanup task. The test definitions (`not_null`, `unique`, `relationships`) take two minutes to write per model and catch data quality regressions automatically on every pipeline run. Documentation written immediately after building the model is accurate; documentation written three months later from memory is wrong in subtle ways that mislead the next analyst who reads it.
Skills that use this tool
Roles that use this tool
Alternatives