A semantic model describes business meaning: entities, relationships, measures, and rules. A semantic layer is the architecture that serves that meaning to consumers. A metrics layer deliberately models less, centering on reusable metric definitions. Vendors use all three terms loosely, which is why your team keeps talking past each other.
Quick Summary (TL;DR)
- The cleanest rule: a model is the artifact that describes meaning, a layer is the runtime that operationalizes and serves it, and one deployed component can be both.
- Power BI semantic model is Microsoft’s specific product name: it is the November 2023 rename of the Power BI dataset, built on the Analysis Services tabular engine, not a new technology.
- dbt confusingly also uses “semantic model” for the YAML entry points inside its Semantic Layer, so the same phrase means different artifacts in Microsoft and dbt ecosystems.
- A metrics store is the productized form of a metrics layer, and despite the name it usually generates queries dynamically rather than storing metric values.
- Headless BI describes delivery: a semantic and query tier exposed through APIs without a bundled visualization front end.
- Consumption is not portability: other tools can query a Power BI model via XMLA, but Microsoft lists only three third-party products as supported semantic models.
- Knowi sidesteps the taxonomy: the governed dataset is simultaneously the model and the layer, serving dashboards, NLQ, and AI agents from one object.
Table of Contents
The Working Taxonomy
No standards body owns these terms, and vendors regularly use the same noun for different things. The table below is a working taxonomy that holds up across products; for the deeper architectural view, start with what a semantic layer is.
| Term | Most useful interpretation | Who uses it this way | What it does not necessarily include |
|---|---|---|---|
| Semantic model | The modeled representation: entities, relationships, measures, security metadata | Microsoft (deployed tabular model), dbt (YAML artifact) | A query service, APIs, caching, or a user interface |
| Semantic layer | The runtime layer that stores or interprets models and serves governed data | Cube, AtScale, Databricks, and most of the market | A specific storage engine or BI interface |
| Metrics layer | A narrower semantic layer centered on metric definitions and valid dimensions | dbt Semantic Layer via MetricFlow | Full domain modeling, hierarchies, app-facing APIs |
| Metrics store | The product packaging of a metrics layer | Transform popularized it; dbt acquired Transform in 2023 | Persisted metric values, despite the word store |
| Headless BI | Semantic plus query serving, decoupled from any front end | Cube popularized the label | It does not mean no UI exists, only that none is required |
The Power BI Confusion, Explained
Microsoft renamed the Power BI dataset to semantic model on November 10, 2023, because “dataset” was too generic inside Fabric. The underlying technology did not change: it remains the Analysis Services tabular engine with tables, relationships, DAX measures, row-level security, and Import, DirectQuery, Direct Lake, or composite storage.
Since September 2025, Fabric no longer auto-creates a default semantic model for every warehouse or lakehouse item, which reinforces the point: a semantic model is a deliberately managed analytical artifact, not an alias for wherever your data lives.
The subtle part is interoperability. Other tools can query a Power BI model through XMLA and REST, but Microsoft’s compatibility documentation lists only SAP BW, multidimensional SAP HANA, and AtScale as supported third-party semantic models, and it warns that stacking one semantic model behind another can produce incorrect aggregations. Being queryable is not the same as being portable.
Why Even Practitioners Disagree
In one widely shared Reddit thread titled “Semantic layer vs Semantic model,” two experienced respondents defined the terms in exactly opposite directions. One called the model the blueprint and the layer its implementation, and the other said they would define the two “exactly backwards.”
The confusion is structural. dbt calls a YAML file a semantic model, Microsoft calls a deployed analytical engine item a semantic model, and Cube calls its modeling, security, caching, and API tier a semantic layer. Same words, different artifacts, which is why capability questions beat label questions when you evaluate semantic layer tools.
Which One Do You Actually Need?
Match the term to your operating model rather than shopping for a category name.
Power BI or one dominant BI tool
Treat the BI tool’s native semantic model as your practical semantic layer. Adding an external product because the name sounds more architectural creates a second model without a second real consumer.
dbt-centric team chasing KPI consistency
A metrics layer is the honest label for the need: governed metric definitions in code, versioned with the transformation project, served to downstream tools.
Multiple BI tools, embedded analytics, or AI agents
Now you need a genuine layer: one governed model served through many interfaces with access control enforced centrally. This is also where AI grounding lives, as we covered in the semantic layer for AI agents.
Cross-source data without a central warehouse
Here the taxonomy gets strained, because most of these products assume warehouse-resident data. Knowi’s approach is to make the governed dataset both the model and the layer: a saved cross-source query carries the definitions, and the same object serves dashboards, NLQ, and AI agents, with glossary terms and certification attached directly to it. There is no separate modeling artifact to keep in sync with a serving tier, which is the failure mode the vocabulary debate usually hides. Our guide on how to build a semantic layer shows what that collapses in practice.
Where Knowi Fits Best
A Microsoft-standardized shop should exhaust the Power BI semantic model before adding anything, and dbt teams with clean marts get real value from MetricFlow’s metrics layer. Knowi fits best when data spans SQL, NoSQL, and APIs, when AI agents are a first-class consumer, and when you would rather govern datasets than maintain a modeling language plus a serving tier plus per-tool models.
Semantic Layer. The essential for your AI BI stack
Finance counts what was booked, sales counts what closed, product counts what was recognized, and your AI picks whichever column looked right. Knowi’s semantic layer records what your business terms mean and exactly which datasets and fields they resolve to, so dashboards, queries, and agents all read from the same definition. It runs on the sources you already have, with no warehouse project first.
What the semantic layer gives you:
- A business glossary where each term maps to specific datasets and fields, not documentation someone has to remember to apply.
- Aliases, so churn, attrition, and logo loss all land on one definition.
- Global alias datasets that normalize values before the query runs, so CA, Calif., and California stop splitting your numbers.
- Certification that marks which assets are trusted, with certified assets ranked higher in Agentic BI chat.
- A catalog of every dataset, source, dashboard, and widget, so people find what exists instead of rebuilding it.
- Programmatic access through the Knowi MCP server, to list terms, map them, and trace how a question resolved.
Built for teams running analytics across SQL, NoSQL, and APIs, where the same metric has to mean one thing in every place it appears.
Frequently Asked Questions
Is a semantic model the same as a semantic layer?
Not exactly. The model is the representation of business meaning, while the layer is the architecture or service that manages and serves it. In a single-tool deployment, one artifact can perform both roles.
Is a Power BI semantic model just a renamed dataset?
Yes, the content type was renamed in November 2023 without replacing the underlying technology. The new name better describes the Analysis Services tabular engine capabilities the item already had: relationships, DAX measures, hierarchies, and security.
What is the difference between a semantic layer and a metrics layer?
A metrics layer focuses on governed measures and the dimensions they can be analyzed by. A broader semantic layer can add richer relationships, hierarchies, security, caching, and application-facing interfaces.
Is a metrics store different from a metrics layer?
The difference is packaging: the layer is the capability, the store is the managed product serving it. Despite the name, a metrics store typically generates queries at request time rather than storing calculated values.
Can other BI tools query a Power BI semantic model?
Yes, mainly through XMLA and Analysis Services compatibility, with varying fidelity. Tableau documents the route while warning of limitations, and Microsoft cautions that layering semantic models can alter aggregation behavior.
Can dbt metrics feed Power BI?
Yes, through a preview connector as of mid-2026, using ODBC and DirectQuery. Aggregation logic stays governed by dbt, several time-granularity limitations remain, and the Power BI Service path requires a gateway.
What is headless BI?
A semantic and query-serving tier delivered through APIs rather than a bundled visualization front end, usually combining modeling, access control, and caching. It includes a semantic layer but describes how the capability is delivered, not a different kind of meaning.