dbt (short for “data build tool”) is an open-source framework that lets data teams transform raw data that already sits in a cloud warehouse into clean, tested, documented tables using mostly SQL. Instead of writing one giant script or clicking through a drag-and-drop ETL tool, you write small models—each one a SELECT statement saved as a file—and dbt figures out the order to run them, materializes them as tables or views, runs tests on the results, and generates documentation and lineage automatically. It is the “T” in ELT: extraction and loading happen first, and dbt handles the transformation inside the warehouse.

Why it matters now: AI agents and conversational analytics tools are only as reliable as the business logic they query. Fivetran and dbt Labs have completed their merger, and the combined company describes its mission as building data infrastructure for trusted AI agents, with ingestion on one side and governed, tested transformations on the other. dbt Labs’ own State of Analytics Engineering report finds AI is now funded and embedded in data teams, while the old problems—data quality, ownership, governance—remain the main constraints. dbt is where many teams encode exactly that logic.

What Problem dbt Solves

Before tools like dbt, transformation logic tended to live in places nobody could audit: stored procedures, scheduled scripts on someone’s laptop, BI tool calculated fields, or spreadsheets exported every Monday. Two dashboards could calculate “active customers” differently, and nobody knew which was right. When a source table changed, reports broke silently.

dbt brings software engineering practices to analytics code. Models live in a Git repository, changes go through pull requests and code review, tests run automatically in continuous integration, and every table has a documented definition. That shift created a new role, the analytics engineer, who sits between data engineering and analysis and spends their time transforming, testing, deploying, and documenting data rather than building one-off reports.

How dbt Works

Models

A model is a SQL file containing a single SELECT. dbt wraps it in the right CREATE TABLE or CREATE VIEW statement for your warehouse (Snowflake, BigQuery, Databricks, Redshift, Postgres, DuckDB and others). You never write DDL by hand; you choose a materialization—view, table, incremental, or ephemeral—in configuration.

The ref() function and the DAG

Models reference each other with {{ ref('stg_orders') }} instead of hardcoded table names. From those references dbt builds a directed acyclic graph (DAG) of dependencies, runs models in the correct order, and can rebuild only what changed downstream. The same graph powers the lineage view, so you can trace a dashboard metric back to the raw source columns. Our explainer on data lineage covers why that traceability matters once AI systems consume your tables.

Tests

dbt ships with generic tests such as unique, not_null, accepted_values, and relationships, declared in YAML next to each model. You can add custom SQL tests and unit tests for tricky logic. When a test fails, the run fails, so bad data is caught before it reaches a dashboard or an AI agent. Model contracts go further by enforcing column names and types, the same idea described in our guide to data contracts.

Documentation, sources, and Jinja

Descriptions written in YAML become a searchable documentation site. Sources declare raw tables and can check freshness. Jinja templating and macros let you reuse logic across models—for example, a single macro that converts currencies or handles time zones consistently.

A Typical dbt Project Structure

Most teams follow a layered pattern: staging models clean and rename raw source columns one-to-one; intermediate models join and reshape; marts expose business-ready fact and dimension tables for analysts, BI tools, and machine learning features. If that sounds familiar, it maps closely to the bronze, silver, and gold layers of the medallion architecture.

Why AI Teams Care About dbt

Governed context for agents. When an LLM-powered assistant answers “What was revenue last quarter?”, it needs one agreed definition of revenue. dbt models, tests, and metrics give it that definition in version-controlled code instead of tribal knowledge. Paired with a semantic layer, those definitions can be exposed directly to AI tools.

Reliable training and feature data. Machine learning features built from tested dbt models are less likely to drift because of an upstream schema change nobody noticed.

AI-assisted development. Because dbt projects are plain text with explicit lineage and tests, AI coding assistants can draft models, write tests, and refactor SQL with much more context than they would get from a black-box ETL tool. The newer Rust-based dbt engine, which dbt Labs is open-sourcing as dbt Core v2.0, is pitched as faster parsing and better performance in exactly these agentic workflows.

dbt Core vs. the dbt Platform

dbt Core is the free, open-source command-line tool you run yourself, typically orchestrated with Airflow, Dagster, or a CI pipeline. The commercial dbt platform (formerly dbt Cloud) adds a hosted IDE, job scheduling, a semantic layer, catalog features, and AI assistance. Many teams start with Core to learn the workflow and move to the managed platform as the project and team grow. The official dbt documentation covers both.

Common Mistakes When Adopting dbt

Recreating old stored procedures as a few enormous models instead of small, testable steps. Skipping tests because “the data looks fine.” Hardcoding table names instead of using ref() and source(), which breaks lineage. Letting every analyst invent their own naming conventions. And treating documentation as optional, which leaves AI tools and new hires guessing what each column means.

If you want to build the SQL, modeling, and testing skills that make data trustworthy for both people and AI systems, explore Coderhouse’s courses below.

• Data Analytics Course — master SQL, data modeling, and the analysis workflow that dbt projects are built on.

• AI Engineering Course — learn to connect AI agents and LLM applications to governed, well-modeled data.

FAQ

Do I need to know Python to use dbt?

No. Most dbt work is SQL plus some YAML configuration. dbt supports Python models on certain warehouses, but solid SQL is the core skill.

Is dbt an ETL tool?

Not exactly. dbt does not extract or load data; it transforms data that is already in your warehouse. It is usually paired with an ingestion tool such as Fivetran, Airbyte, or custom pipelines.

Who uses dbt on a data team?

Analytics engineers are the primary users, but data analysts, data engineers, and increasingly AI engineers contribute models and tests, since the same tables feed dashboards, machine learning features, and AI agents.