Pattern community beginner
dbt as Models + Tests + Docs
Transformation logic lives in untested, undocumented SQL scattered across scripts.
At a glance
| What | Transformation logic lives in untested, undocumented SQL scattered across scripts. |
|---|---|
| When | Warehouse SQL with multiple consumers; A team larger than one |
| Where | dbt |
Problem
Transformation logic lives in untested, undocumented SQL scattered across scripts.
Solution
Every model is code with three faces: model (SQL) + tests (schema.yml) + docs (descriptions) `ref()` builds the DAG; tests encode the invariants; descriptions are the docs site consumers actually read. Materialisation is a deliberate choice per model.
When not to use
- A single ad-hoc query
- Non-SQL-heavy processing
Security scan
Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.
Context
Warehouse transformation with recurring models and consumers.
Forces
- Logic must be reviewable
- Changes must be testable
- New joiners need to understand the lineage
Tradeoffs
| Choose this when | Costs & caveats |
|---|---|
| testable, reviewable, self-documenting transformations | dbt adds a layer to learn; over-testing becomes slow CI |
Diagram
source ─▶ stg_* ─▶ int_* ─▶ fct_*/dim_* ─▶ marts
(tests + docs on every node)
Registry stats
| Verification | community · Sep 26, 2026 |
|---|---|
| Completeness | 75 |
| Trust multiplier | ×1.25 |
| Composite | 35.75 · adequate |
| Freshness | 28 days since last source check |
| Difficulty | beginner |
| Version | 1.1.0 |
| License | CC-BY-4.0 |
| Security flags | none |
Did this solve your problem?
dbt as Models + Tests + Docs