"Semantic model" is a term three different tools will hand you with three slightly different meanings — a Power BI dataset, a dbt spec, an AtScale cube — and a term the AI wave has quietly made load-bearing. This is a plain-language explainer for data leaders and practitioners: what a semantic model actually is, how it differs from the data model underneath it and the semantic layer around it, what Microsoft means when Power BI says "semantic model," and why — when an AI agent is the one asking the question — the semantic model is what decides whether you can trust the answer.
TL;DR
A semantic model is the business-meaning layer of your data — the metrics, dimensions, entities,
and relationships that define what your data means, kept separate from how it's physically
stored. It's what lets people and tools ask for "net revenue by region" instead of hand-writing a
join across ord, cust, and region_dim. It differs from a data model (how data is stored)
and from a semantic layer (the system that serves the model). Power BI uses "semantic model" for
its in-tool dataset; a universal semantic model decouples the same idea from any one tool. In 2026
its most important job is grounding AI: an agent selects certified metrics from the model by name
instead of re-inventing SQL on every prompt. Cube is the agentic analytics platform built on a
semantic layer — its open-source core, Cube Core, is where you define the model.
A working definition
A semantic model is the layer of your analytics that captures what your data means. It defines your business objects — customers, orders, subscriptions — the metrics you measure on them, the dimensions you slice by, and the relationships that connect them. It's the translation from raw, technical tables into the concepts people actually reason about.
The point is to make business meaning explicit and shared. A column named amt in a table named
ord means nothing on its own — is it gross or net, before or after refunds, in cents or dollars? A
semantic model resolves that once: net_revenue is this calculation, over these joins, and every
tool that asks for it gets the same answer. The alternative — the default in most stacks — is that
meaning lives in people's heads and gets re-encoded, slightly differently, in every dashboard and
query. That's how the same meeting ends up with three numbers for "active users."
A semantic model is defined by what it captures, not where it lives. It reads from your data model and is served by your semantic layer — the next two sections pull those two neighbors apart, because they're the terms people most often confuse it with.
Semantic model vs. data model
These get used interchangeably and they shouldn't be. They answer different questions.
A data model describes how data is structured for storage: the tables, columns, data types, primary and foreign keys, and how normalized the schema is. It's designed for a database engine — efficient writes, clean joins, no duplication. (Data modeling is the discipline of getting this right.)
A semantic model describes what that stored data means to the business: which columns compose "revenue," how a customer relates to an order, what qualifies as an "active user," which slices matter (region, plan, month). It's designed for the humans and tools asking questions.
| Data model | Semantic model | |
|---|---|---|
| Answers | How is the data stored? | What does the data mean? |
| Made of | Tables, columns, keys, types | Entities, metrics, dimensions, joins |
| Optimized for | The database engine | People and the tools they use |
| Example | ord.amt is a DECIMAL column | "Net revenue" = sum of ord.amt minus refunds |
You need both. The semantic model doesn't replace the data model — it sits on top of it and reads from it. Get the data model wrong and the semantic model is built on sand; skip the semantic model and every consumer re-derives meaning from raw tables on its own.
Semantic model vs. semantic layer
The other frequent mix-up. The short version: the semantic model is the artifact; the semantic layer is the system that runs it.
The model is the set of governed definitions — the metrics, dimensions, joins, and access rules you author. The layer is the infrastructure around that model: it compiles a request like "revenue by region for the last four quarters" into correct SQL, enforces access rules before the query runs, caches frequent rollups, and exposes the model to every consumer over APIs (SQL, REST, GraphQL, an MCP server for agents, DAX/MDX for spreadsheets).
You author a semantic model; the semantic layer serves it. In casual use the two words blur together — and that's usually fine — but when precision matters, the model is the "what" and the layer is the "how it gets served."
"Semantic model" in Power BI — and the universal version
A lot of people meet the term through Microsoft. In Power BI, "semantic model" is the current name for what used to be called a dataset — the tabular model holding your tables, relationships, and DAX measures that reports query against. Microsoft renamed it precisely because "dataset" undersold what it is: it's a genuine semantic model, with entities, relationships, and governed measures.
The catch is where it lives. A Power BI semantic model is native to the Power BI / Fabric world, so its definitions are available to Power BI and tools that speak its protocols — not universally. If you also run an embedded analytics feature, a Python notebook, and an AI agent, each of those re-implements "active users" again, and you're back to divergent numbers across tools.
A universal semantic model decouples the concept from any single BI tool: one definition of a metric, served to Power BI, other BI tools, embedded apps, spreadsheets, and AI agents alike. (This is also the crux of most Power BI alternatives conversations for teams that have outgrown a single-tool model.) Cube's semantic model is universal in exactly this sense — and, notably, it still serves Power BI natively over DAX, so "universal" doesn't mean "leave Power BI behind."
Why the semantic model matters now: trustworthy AI
The idea isn't new — mapping technical tables to business terms goes back to the OLAP cubes of the 1990s. What changed is the stakes. When the consumer asking the question is an AI agent answering on behalf of a person, the semantic model goes from convenient to load-bearing.
Here's the structural reason. Point an LLM at raw tables and it has to reconstruct your business on
every prompt. Nothing in a SELECT tells it whether revenue is gross or net, which of three tables
that look like "the customer" to join, or that a query just crossed a tenant boundary. So "what was
revenue last quarter?" can return three different numbers across three sessions. That's not a
prompt-engineering problem you patch with one more example — it's a missing model.
A semantic model is that model. The agent selects from certified metrics by name instead of authoring SQL from scratch, so answers are consistent, governed, and explainable — you can see which named metrics produced a number instead of auditing a wall of generated SQL. This is what AI agents need a semantic layer for, and it's the foundation of agentic analytics.
It isn't theoretical. Brex evaluated approaches for grounding AI on their data — including the dbt Semantic Layer and LookML — chose Cube, and built Brex Spaces, an embedded AI financial analyst, on top of it. The reason compresses to one line: the semantic layer is what makes the AI useful — because the model encodes what "spend" actually means at Brex, so the agent doesn't have to guess.
What's in a semantic model
Whatever tool builds it, a semantic model captures roughly the same five things:
| Component | What it defines |
|---|---|
| Entities | The business objects — customer, order, subscription — and their grain |
| Measures / metrics | The numbers you calculate — revenue, MRR, conversion rate — defined once |
| Dimensions | The attributes you group and filter by — region, plan, date, cohort |
| Relationships / joins | How entities connect, including the correct paths through fan-outs |
| Access rules | Who can see which rows and columns — ideally enforced before SQL runs |
The strongest implementations define all of this as code — version-controlled, code-reviewed, and tested in CI — rather than clicked together in a GUI, so the model gets the same engineering rigor as the rest of your stack.
Where Cube fits
Cube is the agentic analytics platform built on a semantic layer, and its open-source foundation, Cube Core (Apache 2.0), is where you define the semantic model: you declare cubes and views with measures, dimensions, and join relationships once, as code, and serve them over SQL, REST, GraphQL, an MCP server for AI agents, and DAX/MDX for spreadsheet tools. Row- and column-level, multi-tenant security is applied at compile time; pre-aggregation caching keeps queries fast. On top of that foundation, the platform adds the AI agent interfaces, workbooks, dashboards, and embedded surfaces — so the same model powers both internal BI for your teams and embedded analytics for your customers.
Two clarifications that come up right away. dbt is a partner, not a thing the semantic model replaces: dbt models and transforms the data; the semantic model governs the metrics and serves them — model in dbt, serve via Cube, which reads dbt models. (Only the dbt Semantic Layer, MetricFlow, is an alternative — and to Cube Core specifically, not the platform.) And a semantic model does not replace your warehouse: it reads from Snowflake, BigQuery, Redshift, or Databricks, which stay your storage and compute.
Our verdict
A semantic model is the business-meaning layer of your data — the metrics, dimensions, entities, and relationships that define what your data means, separate from how it's stored (the data model) and from the system that serves it (the semantic layer). Power BI ships one that lives inside Power BI; a universal semantic model serves every tool and, increasingly, every AI agent from one definition. That universal, AI-native, code-defined model — governed at compile time and served over everything from SQL to MCP to DAX — is what Cube builds, on the open-source Cube Core.
Methodology
This explainer describes "semantic model" as the term is used in 2026 across the data stack, and disambiguates it from the two neighbors it's most often confused with — the data model beneath it and the semantic layer around it — as well as the tool-specific meaning Power BI attaches to it. It's weighted toward the properties that matter when many tools, and increasingly AI agents, read the same model: define-once consistency, access control enforced before execution, and universal serving. As the publisher, Cube builds a semantic layer and an agentic analytics platform on top of it, so we have an obvious interest here; we've tried to define the concept neutrally and be explicit about where Cube fits versus the broader category. Tool-specific behavior (including Power BI's naming) moves quickly — treat it as version-dependent and confirm against current documentation.