dbt
A transformation framework that brings software engineering practice — version control, testing, documentation — to analytics SQL.
How data reaches a decision
What it is
Understanding dbt
dbt transforms data inside the warehouse using SQL, but applies software engineering discipline to it: transformations are version-controlled, dependency-ordered, tested and documented, with lineage generated automatically from the code.
Why it matters
It makes analytics transformations reviewable and testable. The practical effect is that the logic defining a business metric stops being scattered across individual reports and becomes a single, tested, documented definition — which is the actual fix for the "every team reports a different number" problem.
Problems it addresses
- “Business logic is duplicated across dozens of reports.”
- “Nobody can explain how a metric is calculated.”
- “Transformation changes break downstream reports without warning.”
- “We have no lineage from source to dashboard.”
Capabilities
Transformation modeling
Layered, dependency-ordered models with clear boundaries.
Data testing
Uniqueness, referential integrity, freshness and custom business-rule tests.
Documentation and lineage
Generated from the code, so it does not drift from reality.
Semantic definitions
Metric definitions in one place rather than per report.
Use cases
Metric standardization
One tested definition per business metric, used by every consumer.
Transformation governance
Peer review and CI for analytics logic.
Lineage and impact analysis
Know what breaks before changing an upstream model.
Before you commit
Prerequisites, governance and risks
The questions that determine whether this will work in your environment, rather than in a demonstration.
What has to be true first
- A cloud warehouse or lakehouse to transform within
- Version control and code review practice in the analytics team
- Agreement on modeling layers and naming conventions
Governance
The governance value of dbt is that it makes analytics logic reviewable. That only holds if pull requests are genuinely reviewed and tests genuinely gate deployment — otherwise it is version-controlled SQL with extra steps.
Risks
- Model sprawl without layering conventions
- Tests written for coverage rather than for meaningful business rules
- Warehouse cost growth from inefficient model materialization
Where dbt leads
Every connection below is recorded in the content itself, and each one says why it is here.
Technologies
Sectors
Explore solutions using dbt
Open the guided finder with this technology already selected, and see which capabilities apply to your goal, sector and environment — with the reasoning shown.
Start from a goal