Your data lands in a warehouse every night from your CRM, store, ad accounts and billing system. Then someone has to turn those raw tables into numbers people trust: revenue by month, active customers, churn. In many companies that work lives in a pile of saved queries, spreadsheet formulas and one analyst’s memory.

dbt (short for “data build tool”) exists to fix that. It gives transformation work the same habits software teams use: version control, reusable code, automated tests and documentation. This guide explains what dbt does, walks through a simple model, covers testing and docs, and explains what has changed in 2026.

What dbt is in plain English

dbt’s own documentation describes it as a tool that transforms raw warehouse data into trusted data products. You write SQL select statements, and dbt handles the rest: creating tables and views, running them in the right order and recording metadata about what it built.

3 points make dbt easier to understand:

• dbt only does transformation. It does not extract data from your apps or load it into the warehouse. Tools like Fivetran, Airbyte or a custom script handle that part. dbt is the “T” in ELT, which we explain in our ETL vs ELT guide.
• The work runs inside your warehouse. dbt compiles your code and sends it to platforms such as Snowflake, Databricks, BigQuery, Redshift or Postgres. Your warehouse does the computing. See our Snowflake vs Databricks comparison if you are still picking one.
• It is code, not a drag-and-drop tool. Projects are folders of SQL, YAML and Jinja templating that live in Git. That is the point: changes are reviewed, tracked and reversible.

The people who use dbt are often called analytics engineers. They sit between data engineers who build pipelines and analysts who answer business questions. If you already write SQL, you can learn dbt.

How dbt fits in a modern data stack

A typical setup looks like this:

1. Ingest: a connector tool copies raw data from sources into the warehouse.
2. Store: a cloud data warehouse or lakehouse holds raw and modeled tables.
3. Transform: dbt turns raw tables into staging, intermediate and final “mart” tables.
4. Use: BI dashboards, reverse ETL syncs and AI tools read the final tables.

Because each step is separate, you can swap one tool without rebuilding everything. Our explainer on what a data pipeline is covers the full flow and where it tends to break.

A simple dbt model example

In dbt, a model is a single .sql file containing one select statement. The file name becomes the table or view name. Here is a small project for an online store.

First, a staging model that cleans the raw orders table:

sql -- models/staging/stg_orders.sql select id as order_id, customer_id, cast(created_at as date) as order_date, status, amount_cents / 100.0 as amount from {{ source('shop', 'raw_orders') }} where status != 'test'

Next, a mart model that builds on it:

```sql – models/marts/customer_orders.sql {{ config(materialized=’table’) }}

select customer_id, count(*) as order_count, sum(amount) as lifetime_value, min(order_date) as first_order_date from {{ ref(‘stg_orders’) }} group by customer_id ```

2 things are happening here:

• ref() links models. Instead of hard-coding a table name, {{ ref('stg_orders') }} tells dbt that customer_orders depends on stg_orders. dbt uses these references to build a dependency graph (a DAG) and runs models in the right order. Change the staging logic once, and every model downstream picks it up on the next run.
• config() sets the materialization. dbt decides how to build each model in the database. By default it creates a view. The config line above tells it to build a table instead.

Run dbt run (or dbt build, which also runs tests), and dbt compiles the Jinja, writes the create view or create table statements and runs them in your warehouse.

Materializations: how dbt builds each model

The dbt docs list 5 built-in materializations. Picking the right one is mostly a trade-off between freshness, query speed and build cost.

Materialization	What dbt creates	Good for	Watch out for
View (default)	A database view, rebuilt each run	Light staging models, always-current logic	Slow if many dashboards query complex views
Table	A full table, rebuilt each run	Final marts that dashboards hit often	Full rebuilds get slow and costly on big data
Incremental	A table that only adds or updates new rows	Large event or log tables	More logic to get right; needs occasional full refresh
Ephemeral	Nothing in the database; inlined as a CTE	Small reusable logic steps	Can’t be queried directly, harder to debug
Materialized view	A database-managed view with stored results	Fresh data with table-like speed	Support and refresh behavior vary by warehouse

A common starting pattern: views for staging models, tables for marts and incremental models only once a table is large enough that full rebuilds hurt.

Testing your data with dbt

This is where dbt earns its keep. A data test in dbt is a query that returns the rows that break a rule. Zero rows means the test passes.

dbt ships with 4 generic tests you declare in YAML:

• unique: no duplicate values in a column
• not_null: no empty values
• accepted_values: only values from a list you set
• relationships: every value exists in another model (for example, every order’s customer exists in the customers table)

```yaml

models/marts/schema.yml

models: - name: customer_orders description: One row per customer with order totals. columns: - name: customer_id description: Unique customer identifier. data_tests: - unique - not_null - relationships: arguments: to: ref(‘stg_customers’) field: customer_id ```

You can also write singular tests, which are one-off SQL files in a tests/ folder, such as a check that no order total is negative. Packages like dbt-utils and dbt-expectations add dozens more. Separately, unit tests check a model’s logic against fixed sample inputs, so you can catch a broken case statement before it touches production data.

The dbt docs recommend at minimum putting unique and not_null on every model’s primary key. That single habit catches a large share of the duplicate-row and broken-join problems that make dashboards disagree. For a wider view of quality checks, see our guide on how to improve data quality.

Key takeaway: The value of dbt is less about writing SQL and more about the habits around it. Every model is version-controlled, every key is tested and every table is documented, so a wrong number gets caught by a failing test instead of by your CFO.

Documentation and lineage

dbt generates documentation from 2 places: descriptions you write in YAML (like the ones above) and metadata it pulls from your project and warehouse, such as column types and the dependency graph.

Depending on how you run dbt, you get one of these:

• Self-hosted: dbt docs generate builds a static documentation site, and dbt docs serve previews it locally. The site shows model code, tests, descriptions and a lineage graph.
• dbt platform (paid plans): a hosted catalog view called dbt Catalog updates automatically when jobs run, so stakeholders can browse models and lineage without a separate site.

Lineage is the practical win. When a source column changes, you can see every downstream model and dashboard that depends on it before you ship the change. If you need discovery across many tools, not just dbt, a dedicated data catalog covers that wider job.

dbt versions and the 2026 changes

dbt has changed a lot recently, so older tutorials can be confusing. Here is the current picture, based on dbt’s documentation and company announcements:

• dbt v1 is the original Python-based engine, still maintained. Many existing projects run on it.
• dbt v2 is the newer Rust-based engine (known as the Fusion engine), which the docs now recommend and install by default. It is built for faster parsing and a richer editor experience.
• Open source: when Fivetran and dbt Labs announced the completion of their merger on June 1, 2026, they also released dbt Core v2.0 in alpha, open-sourcing the Fusion engine runtime under the Apache 2.0 license.
• dbt platform (formerly dbt Cloud) is the paid hosted service that adds scheduling, CI/CD, hosted docs, monitoring and alerting on top of the engine.

Because v2 was in alpha as an open-source release at the time of writing, check the dbt documentation for current version status and adapter support before migrating a production project. Merged-company branding and packaging may also change.

How much dbt costs

The open-source engine is free to run on your own machine or servers. You still pay for the warehouse compute that runs your models, which is usually the bigger cost.

The hosted dbt platform uses per-seat plans. At the time of writing, dbt’s pricing page lists a free Developer plan with 1 seat, a Starter plan priced per user per month for small teams, and custom-priced Enterprise tiers, each with limits on successful model runs per month. Prices and limits change, so confirm on the dbt pricing page. Our guide to how cloud pricing works explains how warehouse compute adds up.

Where to start with dbt

You can have a working project in an afternoon. A practical path:

1. Pick your warehouse connection. dbt needs a supported adapter for your platform. If you only want to learn, DuckDB or Postgres on a laptop works fine.
2. Install dbt or open a free platform account. Follow the official quickstart for your warehouse.
3. Declare your sources. List the raw tables in a sources.yml file so dbt can track them and test them.
4. Build 1 staging model per source table. Rename columns, fix types and filter junk. Keep it boring.
5. Build 1 mart that answers a real question, such as monthly revenue or active customers. Use ref() for everything.
6. Add tests on every primary key, then relationships tests on key joins.
7. Write descriptions for the mart and its columns, and generate docs.
8. Schedule it. Use the dbt platform, or an orchestrator such as Airflow or Dagster, or a CI job.

If your team is new to SQL, start with our SQL for beginners guide. If you are building a career around this work, our data engineer roadmap shows where dbt fits among the skills employers ask for.

Is dbt right for your team?

dbt is a strong fit when:

• Your data already sits in a cloud warehouse or lakehouse
• Several people write SQL and keep stepping on each other’s logic
• Dashboards disagree and nobody can trace why
• You want reviewable, testable changes instead of edited saved queries

It is probably overkill when you have 1 data source, a handful of reports and nobody comfortable with SQL. In that case a BI tool’s built-in modeling may be enough until you grow. It is also not a replacement for ingestion tools or real-time stream processing, which we compare in batch vs stream processing.

Conclusion

dbt turns transformation from scattered queries into a tested, documented codebase. Start small: a few sources, a few staging models, one mart that answers a question the business cares about and tests on every key. Once that works, the habits scale. Keep an eye on the v2 and open-source changes in 2026, and check the official docs before you upgrade. For more terms, browse our glossary.

Sources

• dbt Developer Hub: What is dbt? — definition, dbt v1 and v2, dbt platform features
• dbt Developer Hub: Materializations — the 5 built-in materializations and default view behavior
• dbt Developer Hub: Add data tests to your DAG — generic and singular tests, unit tests, primary key recommendation
• dbt Developer Hub: Documentation — docs generation, dbt Catalog and lineage
• Fivetran press release: Fivetran and dbt Labs complete merger — June 1, 2026 completion and dbt Core v2.0 under Apache 2.0
• dbt pricing — plan structure for the hosted dbt platform