What is a semantic layer?
Also known as
Metrics layer
A semantic layer is a shared set of definitions for the metrics and dimensions in your data, sitting between the raw data warehouse tables and the tools people use to ask questions. It’s where “revenue,” “active customer,” and “region” get pinned down once, in a form that every chart and query can reuse.
The problem it solves
Ask three teams for last quarter’s revenue and you’ll often get three numbers. Finance excludes refunds and recognizes revenue over the subscription term. Sales counts bookings on the day the contract is signed. The growth team pulls gross charges straight from the payments table. Nobody is wrong, exactly — they’re each answering a slightly different question with a slightly different SQL query, and the differences only surface in a meeting where the numbers don’t match.
The same thing happens to dimensions. “Enterprise account” might mean seat count in one query, contract value in another, and a manually-maintained list in a third. Once those definitions live only inside individual queries, they multiply quietly, and reconciling them becomes a recurring tax on everyone’s time.
A semantic layer moves the definition out of the query and into a shared, named object. Instead of rewriting the WHERE clause that excludes internal test accounts, you reference the definition that already excludes them. When the definition changes, it changes everywhere.
What’s in it
Most semantic layers describe three things: the entities you report on and how they join, the dimensions you can group and filter by, and the metrics — the aggregations, with their filters and their grain. A good one also carries metadata that makes the data legible: human-readable column names, descriptions, units, and formatting.
Note the difference from normalization or star schema design. Those are decisions about how the data is physically stored. A semantic layer is a description of what the stored data means, and it typically compiles down to SQL against whatever tables you already have.
Semantic layers and Metabase
Metabase covers this ground with two building blocks. A model is a curated dataset saved from a question or a SQL query, which you and everyone else can use as the starting point for new questions instead of going back to the raw tables — that’s where joins, cleanup, and column metadata get standardized.
A metric is a saved aggregation, optionally with filters, that people can reuse when building questions rather than re-deriving the calculation each time. Together they let you define “monthly recurring revenue” once and have it mean the same thing on every dashboard that uses it.
If you already maintain definitions in a dedicated tool like dbt, the sensible pattern is to keep that as the upstream source and mirror the definitions into models and metrics, so there’s still exactly one place where a change has to be made.
Related terms
Further reading
Put it to work
- MRR — Metric
- Net revenue retention — Metric
- Revenue analytics — Overview
- MRR dashboard — Dashboard
