dbt (data build tool)
Also known as: dbt, data build tool
dbt (data build tool) is a widely used tool for transforming data inside a warehouse or lakehouse.
Analysts write SQL SELECT statements, and dbt turns them into tables and views, runs them in the right order, tests the results, and generates documentation. While it doesn't move or store any data itself, dbt changed the profession by bringing software engineering habits, like code review and automated tests, to analytics work.
dbt (data build tool), explained at three levels
At home
Imagine a recipe book where each recipe uses the results of other recipes, like making a sauce before the main dish. dbt is the cook that reads all the recipes, figures out the right order, and makes everything in sequence.
At work
dbt helps data teams turn raw data into clean, trusted tables for reports. It keeps the logic in files that can be reviewed, tested, and tracked, instead of hidden in dashboard settings.
At home
Each dbt 'model' is a SQL file. Models can reference other models, and dbt builds a dependency graph so they run in order. Simple tests, such as 'this column is never empty' or 'IDs are unique,' catch data problems automatically.
At work
dbt projects live in Git, run through CI on pull requests, and deploy on schedules or orchestrators. Features include incremental models for large tables, macros using the Jinja templating language, auto-generated documentation and lineage, and a semantic layer for consistent metric definitions.
At home
dbt compiles templates into plain SQL and sends it to the warehouse, which does the actual work. In my opinion, that simplicity is why it caught on: it didn't ask analysts to learn a new engine, just better habits.
At work
Large dbt projects need conventions for layering (staging, intermediate, marts), ownership, and model contracts to prevent breaking downstream users. Watch warehouse costs from full rebuilds, and use incremental strategies and selective runs. Weigh dbt Core (open source) against the managed dbt platform, and follow licensing and product changes after the Fivetran merger announcement.
Real-world examples
At home
Fatima was learning analytics and used dbt Core with a free database to model her running data. Writing a test that caught a duplicated race result made her realize why companies trust dbt for real reporting.
At work
Sophie leads analytics at a Montreal fashion retailer where revenue numbers differed between dashboards. Moving the logic into a tested dbt project with one shared revenue model ended a long-running argument between finance and marketing.
Common confusions
- dbt moves data from source systems into the warehouse. — dbt only transforms data already in the warehouse. Loading is done by other tools.
- dbt is a database. — dbt sends SQL to your existing warehouse or lakehouse, which stores and processes the data.
- dbt is only for engineers. — It was designed for analysts who know SQL, which is a big part of its popularity.
For analysts
If two dashboards show different numbers for the same metric, the fix is usually one shared definition, not another meeting. I'd use dbt models and tests to make that definition visible and enforced.
History & origin
Tristan Handy created dbt in 2016 at his consultancy, Fishtown Analytics, to help clients manage SQL transformations in cloud warehouses. It spread through a large online community and helped define the 'analytics engineer' role. Fishtown renamed itself dbt Labs in 2020 and raised large venture rounds as the modern data stack boomed. In 2025, dbt Labs introduced a new engine, dbt Fusion, built on technology from its acquisition of SDF Labs. In October 2025, dbt Labs and Fivetran announced plans to merge. In my view, dbt's lasting contribution is cultural: it made 'just tweak the SQL in production' feel as reckless in analytics as it already did in software.