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
Think of a cookbook where some recipes use the results of others: you make the sauce before the lasagna. A good cook reads all the recipes, works out the right order, and checks each dish before serving it. dbt does that for data. Each recipe is a SQL query, and dbt runs them in the right order inside the database and tests the results.
At work
dbt, the data build tool, lets data teams turn raw warehouse data into clean, trusted tables using SQL. Each transformation is stored as a file in version control, tested automatically, and documented. dbt doesn't store or move data itself; it sends SQL to your existing warehouse. Businesses care because reporting logic becomes visible and reviewable, instead of hidden inside dashboards where numbers quietly drift apart.
At home
In dbt, each model is a SQL file containing one SELECT statement. When a model refers to another using the ref function, dbt records that link and builds a dependency graph, so models run in the right order. dbt wraps each query so the warehouse saves the result as a table or view. Tests are small checks, such as 'this column is never empty' or 'IDs are unique,' run after each build.
At work
At work, a dbt project lives in Git and runs through CI on every pull request, often building only changed models and their dependents. Models are layered: staging cleans source tables, intermediate models join them, and marts serve reporting. Features include incremental models that process only new rows, Jinja macros for reusable logic, auto-generated documentation with lineage graphs, model contracts that enforce column types, and the dbt Semantic Layer for shared metric definitions.
At home
dbt is essentially a compiler. It reads your SQL and Jinja templates, resolves every ref into a real table name, orders the models by dependency, and sends plain SQL to the warehouse, which does all the actual computing. While that means dbt can't rescue a slow warehouse, 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: layered models, clear ownership, model contracts and versions so changes don't break downstream users, and selective runs to control warehouse costs. dbt Core is open source, while the managed dbt platform adds scheduling, a browser-based editor, and the Fusion engine, a faster rewrite with deeper SQL understanding. Fivetran and dbt Labs completed their merger in June 2026, so review licensing and roadmap commitments before signing long-term contracts.
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 2021 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 a merger, which closed in June 2026. 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.