This publication may be a little provocative - I’m (once again) questioning whether you really need a semantic layer. But this time, I’m also questioning whether you have the right people owning your data models, and whether investing in the modern data stack will make your company “AI-native” or finally make self-serve analytics (whatever that means) work.
Today, I’m going to try to prove 3 claims:
You probably don’t need a semantic layer if you have strong dbt models. Well-designed marts should provide enough business meaning for both analysts and AI agents. Think twice if you really need another abstraction layer on top of it.
dbt models can be enough - but only *if* an analyst built them. Or, better - if they were designed by someone who understands the business questions they need to answer, and not only the origin of source data or ways it needs to be transformed (this is where too many analytics engineering projects stop).
Which brings me to: your data lead needs BI instincts (even if BI is not in their title). The person leading your data initiatives should have spent enough time in BI to know how people use, combine, and misuse data and potential damage from it (e.g., over-reporting MAU is annoying but not as harmful for the business as under-reporting churn).
Read below on the difference between semantic layer vs data model vs metrics layers, with examples for each, and how to set up dbt to serve both analysts and AI agents well.
Why we can’t agree on what semantic layer is
Semantic layer is the most misunderstood concept in data. Many people think of it as an aggregated layer of predefined metrics and formulas built for BI tools. But it is (or at least can be) much more than that.
One reason we can’t agree on its definition is that the term means different things depending on the data stack being used. For example, Power BI or Looker has a built-in semantic layer that provides a layer of security, defines metrics, and implements hierarchies. In this case, the semantic layer and the metrics layer are combined. But other data stacks separate the transformation layer, semantic layer, and metrics layer, and then there is a new generation of tools designed to sit at different stages of data processing.
For example, a few weeks ago, George Xing wrote a wonderful piece How AI revived semantic layers and the quest for self-serve analytics. It is one of those must-read takes on the modern data stack, but once again, the history of semantic layers is presented as a Looker supplement, when in fact it’s so much more.
I think of a semantic layer as a standalone, warehouse-centered product that can serve multiple domains. It may be driven by BI needs, but it can also support ML, security, integrations, APIs, and operational workflows.
Even more, reducing the semantic layer to a BI-only (which is a common setup) is dangerous. Many BI tools don’t have version control or a formal deployment process, there is lack of visibility into definitions. Which means, you likely won’t be able to reproduce the same metric in another tool. This makes it harder to scale, creates multiple sources of truth, and leaves different systems reporting different answers to the same question.
