Executive Summary: A semantic layer defines business metrics and computes them on request. A universal semantic layer makes those definitions available across AI agents, BI tools, and spreadsheets, reducing duplicated logic. An AtScale customer-count example shows the distinction. Shared definitions still take agreement and review to get right.
Key Takeaways:
- “Semantic layer” describes different capabilities. Ask where the metric is defined and what turns it into a number.
- A universal semantic layer lets multiple tools use the same business definitions without rebuilding them.
- Given the same data and permissions, changing tools shouldn’t change the answer.
- Shared definitions still need agreement and review. A consistently calculated metric can still be wrong.
I kept running into “semantic layer” meaning different things, which made it hard to tell when you’d actually need one. Depending on where you look, it could mean views over a warehouse, a data catalog, dbt models, or the business logic inside a BI tool.
This is the second post in one hundred days of learning semantic layers in public. The first one, The Missing Step in Text-to-SQL, was about disambiguating a question with two correct answers.
Four things people think a semantic layer is
1. Is a database view a semantic layer?
Sometimes people mean a set of views over the warehouse. Turn fact_purchase into vw_sales, give the columns names people recognize, and hide the aggs and joins.
That’s useful work. A well-designed view saves analysts from untangling the same schema every time they ask a question. It also gives downstream queries a stable interface when the underlying tables change.
The boundary appears when friendly columns still leave the business logic to the person querying them. Units sold might be a sum. Average selling price needs a calculation. Distinct customer counts can’t simply be added across regions when customers buy in more than one.
You can encode those rules in SQL. Does every consumer use the same rule, or does each analyst have to supply it? A view can be part of that answer. Having views doesn’t automatically settle it.
2. Semantic layer vs. data catalog: what’s the difference?
Another perspective is that the semantic layer is where you go to find out what the data means. Think of a catalog or metadata platform like Alation, Collibra, or Atlan: tables, columns, owners, descriptions, and lineage.
If your first question is “Which revenue table should I trust, and who can explain it?”, a catalog is doing the job you need. Finding the approved definition is a prerequisite for using it. Alation describes this role as helping people find, understand, and trust their data.
But documenting a calculation and executing it are separate jobs. A glossary can tell you that revenue excludes refunds. Something still has to apply that rule when someone asks for revenue last quarter.
What turns the documented definition into the number?
These capabilities belong together. AtScale, for example, provides connectors that push model metadata into Alation and Collibra, making the models discoverable through the catalog. AtScale’s connector documentation describes that relationship. The connection runs both ways. CoModel can read a catalog’s glossary of business terms and build a semantic model from them, so the definitions an organization already agreed on become the ones that compute.
3. Is the dbt Semantic Layer a universal semantic layer?
“Isn’t that what we use dbt for?” is a reasonable response. A lot of business meaning already lives in the transformations that turn raw data into usable models: which records count as orders, how customers are identified, how refunds are handled. Keeping that logic in version control where it can be tested and reused beats rebuilding it in every report.
There’s also an important distinction within dbt itself. Transformation models produce tables or views. MetricFlow defines metrics and generates SQL when they’re queried, and the dbt Semantic Layer exposes those metrics through APIs and integrations. That’s semantic-layer functionality, including serving multiple tools. dbt explains the architecture here.
Does our dbt setup serve the metric to every consumer we need, in the way they need to query it?
“We use dbt” doesn’t answer that. You have to distinguish the transformations you’ve built from the metric-serving capabilities you’ve deployed.
4. Semantic layer vs. a Power BI or LookML model
Then there’s the model inside the BI platform: LookML, a Power BI semantic model, or a Tableau data source. Relationships, measures, business names, calculations. These let someone build a report without starting from raw tables.
These can be sophisticated models. If your team has already agreed on revenue and encoded it there, you’ve done real semantic modeling.
And those definitions aren’t necessarily trapped inside one interface. Power BI supports live connections from Excel, and Looker’s Open SQL Interface exposes LookML models to compatible JDBC clients. Microsoft’s Excel documentation and Looker’s interface documentation describe those options.
Can another tool query the existing definition, or will someone rebuild it?
Those connections are real, and they run one way. The model lives inside the BI platform and follows that platform’s lifecycle. Another client can read it. The definition itself doesn’t leave.
When a second team standardizes on a different tool, the options narrow. Sometimes you can connect back through the first tool, which keeps the platform you were moving away from in the query path, and the second tool gets only what that interface exposes. Sometimes you can’t, because those interfaces are built for a particular kind of client.
What’s left is rebuilding the metric. Do that and you have two definitions of revenue to keep in sync. A definition’s reach stops at the tool that owns it. Past that, you’re routing through it or rewriting it.
How a semantic layer defines and computes a metric
A semantic layer holds your business definitions in one place and computes them on request for anything that asks.
A definition without an engine is a glossary; it never returns a number. An engine without shared definitions is a query tool: fast, and everyone gets their own answer. You need the file that says what “customer count” means, and the engine that computes it.
The example below runs on AtScale.
Here is the definition of the customer count metric:
unique_name: Customer Count
object_type: metric
label: Customer Count
description: “Distinct customers / unique buyers who placed internet sales orders. Exact distinct count; contrast Estimated Customer Count (approximate, faster).”
calculation_method: count distinct
format: general number
dataset: factinternetsales
column: customerkey
It’s one file, kept in Git and reviewed like any other change in your SDLC.
The business rule is calculation_method: count distinct. The total requires a distinct count across customers, rather than a sum of the regional counts.
dataset and column connect that rule to the underlying data, in this case, factinternetsales.customerkey. Keeping that mapping in the model gives you a central place to maintain it as the data changes.
The description helps explain which metric to use. Here, it distinguishes an exact customer count from an estimate. That context matters to someone browsing the model and to an agent choosing a metric to answer a question.
The definition doesn’t specify “by region,” “by month,” or “national total.” Those come from the question. The engine uses the measure, along with the model’s relationships and dimensions, to compose the query and apply the same business rule each time.
Here is an example of querying that customer count metric via Claude through AtScale MCP:
Through MCP, Claude requests “Customer Count” from AtScale, which calculates the result using the shared metric definition. AtScale’s universal semantic layer sits between the data and your analytics tools, making that same definition available to each supported tool. Any tool connecting through the layer gets that same definition, computed the same way.
What makes a semantic layer universal?
Companies rarely use one interface for everything. Finance works in Excel, analysts use BI tools and notebooks, and an AI assistant needs access to the same business logic. When a new tool arrives, someone often translates “customer count” into another model. From there, definitions can drift. One team changes how it handles duplicate customers; another keeps the old logic. Both reports still say “Customer Count.”
AtScale’s universal semantic layer makes that business model a shared service. Each supported tool connects through an interface it understands, while the layer applies the definitions and relationships. Changing the tool shouldn’t change the answer.
The definition is maintained once and served wherever it’s needed.
What a semantic layer doesn’t solve
- Agreement takes work. Modeling takes time, and a tool can’t decide what “revenue” should mean for your business.
- A shared definition can still be wrong. Serving it consistently can spread an error and make it easier to trust, so definitions need testing and review.
- Not every question needs a modeled metric. Ad hoc exploration remains useful, especially when you’re investigating unfamiliar data or deciding what to model.
The definition should survive the next tool
Agreeing on what “customer count” means takes work. Once that agreement is captured in a model, it should remain useful when someone opens a spreadsheet or points an agent at the data. Each new interface should give people another way to use that work without creating another definition to maintain.
That gives us a practical way to evaluate a semantic layer: follow a metric. Find where it’s defined, see how it’s calculated, and trace what happens when another tool asks for it. How much of the original definition is available to your tools? How much has to be written again?
As the tools we use to ask questions change, the business definitions behind the answers should travel with us.
Learn about the AtScale universal semantic layer on the AtScale Academy.
Frequently Asked Questions
Often both. dbt prepares the data, and MetricFlow defines metrics and generates SQL when they’re queried. The deciding question is which consumers you have to serve: if an Excel user wants a live PivotTable or an agent needs to browse the model and pick a metric by name, check whether those paths exist before assuming the definition travels.
They do different jobs, and plenty of organizations run both. A catalog is where a definition gets written down and agreed on, with owners and lineage attached so people can find it and trust it. A semantic layer is where that definition gets computed, so what comes back is a number rather than a description. AtScale pushes model metadata into Alation and Collibra, so models stay discoverable through the catalog people already use.
Data virtualization separates the logical query from the physical one, so a tool queries a model instead of the tables underneath, and AtScale is built on it. Federation is the related idea people usually mean: joining disparate sources in a single query at runtime. AtScale connects to many sources, but a given model reads from one of them.
Neither virtualization nor federation decides what revenue means. A semantic layer holds that definition and computes it when something asks.
Yes. An agent connects through an interface like MCP, reads the model to see which metrics exist, and asks for one by name. It gets the computed number back instead of writing its own SQL against raw tables, so it never has to work out what “customer count” means on its own.