Semantic Layer vs. Metrics Layer: What's the Difference?

A metrics layer defines the numbers. A semantic layer defines the numbers and the model around them — the entities they belong to, the dimensions you can slice them by, the paths between tables, and the rules about who can see what.

That's the whole distinction, and for years it didn't matter much. It matters now because AI agents ask questions nobody wrote down in advance.

Why the terms drifted together

"Metrics layer" and "metrics store" entered the vocabulary around 2021, describing a specific fix for a specific pain: the same metric implemented slightly differently in every dashboard, so nobody could say which "revenue" number was right. Centralizing the definitions solved that.

Then two things happened. Metrics-layer products grew — once you're defining a measure, you need to say what it can be grouped by, which means dimensions, which means entities, which means joins. And semantic-layer products, which had modeled all of that since the OLAP era, started leading with their metrics because that's the pain buyers recognized.

The result is that today most tools called a metrics layer are, structurally, semantic layers with a narrower emphasis. It's more useful to treat "metrics layer" as a scope — the measures — than as a distinct product category.

What each one actually contains

A metrics layer, in its narrow sense, holds:

• Measures — revenue, active_users, gross_margin, each with an agreed formula
• Usually some notion of valid dimensions for each measure
• Often ownership and description metadata, so people know who defined it and what it means

A semantic layer holds all of that, plus:

• Entities — the business objects the measures belong to: customers, orders, subscriptions
• Dimensions — the attributes you can slice by, defined once with their own logic
• Join paths — how the entities relate, so a query can traverse from an order to the account that placed it to the region that account sits in
• Access rules — row-level and column-level policies, evaluated before SQL is emitted rather than filtered afterward
• Query-time extensibility — the ability to compose new calculations on top of governed definitions without editing the governed definitions

The difference in practice: one question

Take a question a business user might actually ask:

"What was net revenue by acquisition channel for enterprise accounts in EMEA last quarter?"

A metrics layer can hand back net_revenue correctly. Whether it can answer the full question depends entirely on whether someone anticipated this combination — net revenue, sliced by acquisition channel, filtered to a customer segment and a region. If that combination wasn't registered, the layer returns the metric and the consumer is on its own for the rest.

A semantic layer resolves the whole thing, because it knows that an order joins to an account, that an account has a segment and a region, and that acquisition channel is an attribute of the account's first touch. It composes the SQL, applies the access rules, and returns one number.

The gap between those two outcomes is small when a human analyst is in the loop — they'll write the join themselves. It's decisive when the thing asking is an agent.

Why AI made this distinction load-bearing

Point an LLM at raw warehouse tables and it will write SQL. It will also, on every prompt, re-derive which table to join to which, what counts as an active customer, and whether refunds are subtracted before or after discounts. Ask the same question twice, phrased differently, and you can get two different numbers — both plausible, both confidently reported.

A metrics layer helps but doesn't close this. It gives the agent certified measures; it doesn't necessarily give it the entity graph needed to slice those measures in a way nobody pre-registered. The agent still improvises the parts that weren't covered, and the improvised parts are where wrong answers come from.

A semantic layer for AI agents closes it, because the model contains the joins and the access rules. The agent's job becomes selecting from certified definitions rather than reconstructing them. That's what Brex meant in choosing Cube over the dbt Semantic Layer and LookML: the semantic layer encodes what "spend" means at Brex, which is what makes the agent's answers useful rather than merely fluent.

This is also where the governance-versus-flexibility tradeoff dissolves. The usual choice is to lock the model down until nobody uses it, or open it up until there are fifteen definitions of "churn." A SQL-first semantic layer that's extensible at query time keeps the governed definitions fixed while letting agents and analysts build ad-hoc calculations on top of them.

How to tell which one you're looking at

Four questions that sort a product quickly:

1. Can it answer a question that combines a measure with a dimension nobody registered together? If yes, there's an entity model underneath. If it needs the combination pre-defined, it's a metrics layer in the narrow sense.
2. Does it know how your tables join? A semantic layer holds the join graph. A metrics layer often assumes someone else resolved that.
3. Where are access rules enforced? A semantic layer evaluates them before generating SQL. If filtering happens in the consuming tool, each tool has to be trusted to do it correctly.
4. Are the definitions code? SQL-first models in version control can be reviewed, diffed, and tested. UI-only definitions can't.

Where Cube fits

Cube Core is the semantic layer — open source under Apache 2.0, and the original Cube project. It defines measures, dimensions, entities, join paths, and access rules in SQL-first models that live in version control, on top of the warehouse you already run: Snowflake, BigQuery, Redshift, or Databricks. It reads dbt models directly, so transformation stays in dbt and query-time governance lives in Cube.

Cube is the agentic analytics platform built on that foundation. The same governed definitions serve Analytics Chat for natural-language questions, workbooks and dashboards for internal BI, embedded surfaces for customer-facing analytics, and an MCP server so agents in Claude or ChatGPT answer from certified metrics. One model, every surface — which is the practical form of the distinction this article is about.

If your immediate problem is that two dashboards disagree about one number, a metrics layer will solve it. If the next thing on your roadmap is an AI agent answering freely, or analytics embedded in your product, you'll want the entity model underneath — which is the semantic layer.

Methodology

Definitions here follow how the terms are used across current semantic-layer and metrics-layer product documentation as of August 2026, not a single vendor's glossary. We build Cube, so the closing section is explicitly about our own product; the preceding sections are written to hold regardless of which tool you pick. Where the industry genuinely uses a term loosely — as it does with "metrics layer" — we say so rather than inventing a crisper distinction than exists.