dbt fixed the transformation layer. Models are tested, versioned, documented, and defined once in code instead of once per analyst. Connect a BI tool on top, though, and half those same metrics get redefined again as calculated fields inside it. That's the real question behind a dbt reporting layer. Once a metric is defined in dbt, does anything downstream actually read that definition? Or does every dashboard just derive its own?
What dbt actually solves
dbt turns "someone's SQL script" into a version-controlled model. It ships with tests, documentation, and a lineage graph showing exactly what feeds into what. A metric built in dbt is reviewed, tracked in source control, and reproducible. That's a real improvement over logic that used to live in one analyst's head, in a folder of ad hoc scripts. Take a model like monthly_active_users. Before dbt, that definition lived in whichever analyst last touched the query, and it changed quietly every time someone did. In dbt, it's one model. A test fails the build if the logic breaks. A lineage graph shows every downstream table that depends on it.
What it doesn't solve
dbt models land in tables. Most BI tools then let — or effectively force — every dashboard author to redefine "active user" or "net revenue" again. The redefinition happens in the tool's own calculated-field language. The BI layer doesn't know a metric was already defined upstream. The definition escapes the version-controlled layer the moment it hits a dashboard. You're back to the same drift problem dbt was supposed to fix, just one layer higher up. Picture two dashboards, one built by marketing and one by finance. Both claim to show "net revenue." They can disagree — not because the underlying data is wrong, but because each tool derived the number its own way.
The gap between a dbt metric and what a dashboard shows
dbt's own semantic layer and metrics tooling address part of this directly. But the benefit only shows up if whatever sits downstream actually reads those metric definitions. Otherwise it just re-derives its own aggregation from the underlying tables. A BI tool that ignores the metrics layer, and queries the raw model tables directly, puts you right back where you started. The raw tables are better documented. The drift underneath is the same. Say the dbt metrics layer defines net_revenue as gross bookings minus refunds and discounts. A BI tool that reads that definition through the metrics API inherits it, every time. A BI tool that queries the raw orders table instead, and re-aggregates from scratch, can net out refunds differently, or skip discounts entirely. Nothing in the tool will flag the mismatch.
What to check before adding a dbt reporting layer
- Does the reporting layer consume dbt's model output directly, or does every dashboard re-model the aggregation from scratch?
- Can an analyst still write raw SQL against the warehouse when a new question doesn't fit an existing model, without leaving the tool?
- If a metric's definition changes in dbt, does it propagate downstream, or does someone need to make the same edit twice?
None of these questions are about which BI tool to buy. They're about whether the reporting layer already in place treats dbt's models as the source of truth, or as just another table to query. A reporting layer that ignores dbt's definitions is just a well-documented way to end up in the same place.
Where Veritly sits
Veritly connects directly to the warehouse dbt already builds. dbt is one of the connectors teams wire up on day one. The governed semantic model on top doesn't ask you to redefine what dbt has already defined well. One semantic model resolves every dashboard, document, and job downstream of it — dbt's models included. That's what a dbt reporting layer is supposed to do. It keeps the definition in one place, all the way through to the dashboard.
A metric still needs exactly one owner, even after the transformation layer is solid. That owner should be able to query it in plain English. Veritly shows the SQL behind the answer, and builds the dashboard from it. No exporting to yet another tool that re-derives the number its own way.
Join the private beta waitlist — early access includes a setup session with the team that built it.
Related reading: semantic layers explained, and what an integrated analysis environment is.
See also: what a data warehouse is.
