Quick answer:
A semantic layer is a shared dictionary of business definitions that sits between your data and your tools. It pins down, once and centrally, what “revenue”, “active user”, and “churn” mean in SQL terms, so every dashboard, spreadsheet, and AI assistant computes them the same way instead of five analysts writing five slightly different queries.
It exists to kill the most expensive sentence in analytics: “which number is right?”
What is a semantic layer?
Underneath every metric is a pile of decisions. Does revenue include refunds? Which timestamp counts, order placed or payment settled? Is an “active user” 7-day or 30-day? None of these answers live in the raw tables; they live in whoever wrote the query.
A semantic layer moves those decisions into code, in one governed place. You define metrics (the calculation), dimensions (what you can slice by), and how tables join. Tools then ask the layer for “revenue by region, last quarter” and the layer generates the correct SQL. The consumer never re-implements the logic, so the logic can’t drift.
Where did the idea come from?
It’s had 3 lives. Business Objects sold “universes” (the same concept, dressed for the 1990s) decades ago. Then Looker made the modern version famous with LookML: define your model once, and every explore and dashboard in the company speaks it. LookML was arguably the product; the charts were the demo.
The third life is the standalone, headless semantic layer: definitions living outside any one BI tool, served to all of them through APIs. dbt Labs bought Transform in 2023 and folded its MetricFlow engine into the dbt Semantic Layer; Cube built a business on the same idea. The bet is that metrics belong with the transformation code, and BI tools become interchangeable screens.
How is it different from just modeling your data well?
Clean modeled tables (the dbt layer of the stack) get you far, and plenty of teams stop there. But a table can’t express “monthly recurring revenue, excluding trials, normalized to 30-day months”. Someone still writes that aggregation in every tool that needs it.
The semantic layer covers exactly that last mile: aggregations, ratios, time-window logic, and the joins between clean tables. Modeled tables define the nouns; the semantic layer defines the verbs and the arithmetic.
Why does this suddenly matter for AI?
Because text-to-SQL is only as good as its grounding. Ask an LLM “what was churn last month?” against raw tables and it will confidently invent a definition of churn. Ask it against a semantic layer and it has to pick from the governed metrics, which turns a hallucination problem into a lookup problem.
Every vendor building “chat with your data” has figured this out, which is why semantic layers went from a niche architecture debate to a roadmap item everywhere in about 2 years. Metabase‘s metrics explorer, Looker’s role inside Gemini, dbt’s MCP server: same instinct, different wrappers.
What are the benefits and drawbacks of a semantic layer?
Benefits of a semantic layer
One definition, everywhere
Revenue computed identically in the BI tool, the spreadsheet export, and the AI assistant, because they all asked the same layer. The “which number is right?” meeting dies of starvation.
Change logic once
When the business redefines churn, you edit one metric definition instead of hunting through 40 dashboards for embedded copies. The blast radius of a definition change collapses.
Self-serve gets safer
Non-analysts explore by picking governed metrics and dimensions instead of writing joins from scratch. The layer quietly prevents the fan-out mistakes that make self-serve SQL dangerous.
AI gets a vocabulary
Text-to-SQL against governed metrics turns “invent a definition of churn” into “select the churn metric”. Grounding for numbers, the way RAG is grounding for documents.
Drawbacks of a semantic layer
Someone has to own the dictionary
Definitions demand maintenance, review, and the political work of getting finance and product to agree on one revenue formula. The technology is the easy half.
Another hop, another suspect
Generated SQL adds a layer between analyst and warehouse. When a number looks off, debugging now includes “what did the layer generate?”, and performance tuning gets less direct.
Standalone layers fight the BI tools
Every BI product wants to be the semantic layer, and external ones integrate unevenly (great with tool A, half-supported in tool B). Check your exact combination before believing the diagram.
Premature abstraction is a real cost
A 5-person startup encoding 12 metrics into dedicated infrastructure has bought governance for a problem it doesn’t have yet. A wiki page would have done.
Should your team build one?
Honest answer: start smaller than the category wants you to. If your company runs one BI tool, that tool’s built-in modeling (LookML, Metabase models and metrics) already gives you 80% of the value with none of the extra infrastructure.
A standalone semantic layer earns its keep when metrics feed multiple destinations (BI plus spreadsheets plus embedded analytics plus an AI assistant) and inconsistency between them has real costs. That’s a real problem at real scale, but it arrives later than the marketing suggests. Until it does, a well-modeled warehouse and one agreed revenue definition, written down where people can find it, beat any product you can buy.