LookML and dbt made the same bet: definitions belong in code that humans write and review.
The next question is whether a human should be writing them at all.
Both were right about the problem
Scattering metric definitions across dashboards was genuinely bad. Version control, review, reuse — real engineering discipline applied to meaning. That was a step forward and it stuck.
The shared constraint
| LookML | dbt Semantic Layer | Compiled layer | |
|---|---|---|---|
| Authored by | Engineers, by hand | Engineers, by hand | Generated from your sources |
| Coverage equals | Authoring effort | Authoring effort | Estate size |
| New concept | A pull request | A pull request | Resolved on demand |
| Schema change | Maintenance debt | Maintenance debt | Drift detected automatically |
| Governance | Dashboards and folders | Upstream in the warehouse | Compiled into every query |
| Undefined question | Ticket | Ticket | Resolved or explicitly refused |
The first two rows are the whole comparison. Everything else follows from them.
Why it matters more now than it did in 2019
When the consumer was a human analyst filing a ticket, "coverage equals authoring effort" was an acceptable trade — the request rate was bounded by how fast people could type.
Agents don't have that bound. They ask at machine rates, about things nobody anticipated, and a modelling backlog becomes the system's effective capacity.
The honest framing
This isn't LookML vs dbt. Those two differ mainly in syntax and ecosystem, and either can be the right choice for analytics engineering discipline.
The real axis is whether your semantic coverage scales with your data or with your headcount. That's the question that decides the next five years, and neither hand-authored option answers it well.
The full breakdown — the three-way comparison, migration considerations, and where each fits in a modern stack — is here:
👉 LookML vs dbt Semantic Layer vs a Compiled Semantic Layer
Originally published at colrows.com/blogs/lookml-vs-dbt-semantic-layer
Top comments (0)