dbt is the transformation layer that turns raw loads into a clean, traceable data model. Versioned, testable, documented. Exactly the foundation reliable BI and AI build on.
What is dbt?
dbt is the T in ELT. Data lands raw in the warehouse, dbt transforms it there into versioned SQL models, with tests, lineage, and docs. The logic no longer lives scattered across BI tools and scripts, but in one place, under version control.
That sounds like engineering discipline, and that's exactly what it is. The effect: a metric is defined the same way everywhere, an error is traceable, and new team members read the model instead of guessing it.
When dbt fits, and when it doesn't
A fit when:
- multiple sources converge into one consistent model
- the same definitions feed multiple dashboards
- data quality and lineage need to be verifiable
- a team brings SQL and git discipline
Less so when:
- only a single report is needed
- there's no modelled data foundation to transform
- nobody maintains the models
Without dbt vs. with dbt
| Criterion | SQL in the BI tool | dbt |
|---|---|---|
| Definitions | duplicated per dashboard | once, central |
| Tests | manual, if at all | on every build |
| Traceability | hard | lineage and docs |
| Versioning | none | git |
| Onboarding | knowledge in someone's head | a readable model |
What Datascale builds with dbt
We set up the model and keep it maintainable:
- project structure, staging and mart layers
- models for the core marketing and revenue metrics
- tests against silent data errors
- orchestration via Dagster or dbt Cloud
- lineage and docs for your team
- connection to BI and, where it helps, to the AI layer
The full picture lives in Data Platform & Governance: lakehouse, modelling, tests, and governance in one. With us, dbt usually runs on BigQuery, fed from sources like funnel.io or Snowplow.
