Power BI Semantic Models Explained: 2026 Guide

---

A Power BI semantic model is the layer where a business calculation stops being one analyst’s formula and becomes the company’s number. Atlan catalogs those models, parses their Power Query expressions into column-level lineage, and links the definitions inside them to the same terms defined in dbt, the warehouse, and every other semantic layer an enterprise runs. That is the difference between a metric that is consistent inside Power BI and one that holds across the whole estate, which is what an agent needs before it can answer a question it was not shown the dashboard for.

Aspect	Detail
Former name	Power BI dataset, renamed to semantic model in November 2023.
Underlying engine	Analysis Services tabular model, queried with DAX.
Storage modes	Import, DirectQuery, and composite, which sets Import, DirectQuery, or Dual per table.
Security	Row-level and object-level security defined as model roles, with workspace and item permissions controlling everything else.
Size limits	1 GB by default, 100 GB on Premium Per User, and up to capacity memory limits with the large semantic model storage format.
Refresh limits	Eight scheduled refreshes a day on shared capacity and 48 on Premium capacity, with no 48 cap on XMLA refreshes.
Trust signals	Promoted, Certified, and Master data endorsement, applied to the item in the service rather than stored in the model.
Source control	Power BI Desktop projects in preview, saving models as TMDL text files for Git.
External access	XMLA endpoint on Premium, Premium Per User, and Embedded workspaces, plus Fabric and Power BI REST APIs.
AI access	Copilot, Prep data for AI settings, and the remote and local Power BI MCP servers in preview.

---

What does a Power BI semantic model do?

A Power BI semantic model is the governed data model that every Power BI report, dashboard, and Copilot answer queries behind the scenes. Each model bundles data, logic, and access rules into one deployable item.

Until late 2023, Power BI called this object a dataset. Microsoft changed the name to semantic model for two reasons:

• Dataset was too generic: the word carried different meanings across the many data experiences inside Microsoft Fabric.
• Semantic model fits the capability: the new name describes the modeling depth Analysis Services provides.

Nothing changed functionally, so older documentation and some APIs that still say dataset refer to the same object. Atlan’s Power BI connector, for example, catalogs these models as Power BI datasets.

The value is a single version of a calculation, and increasingly, grounding for AI answers. Semantic grounding has a measurable effect on accuracy. In dbt Labs’ 2026 benchmark, Claude Sonnet 4.6 scored 90.0% with raw text-to-SQL and 98.2% through a semantic layer on questions the layer could answer. Atlan AI Labs saw the same pattern: enriching schema with glossaries, SQL usage patterns, and domain hints produced a 38% relative gain in SQL accuracy, which is why text-to-SQL for enterprise work now starts with definitions rather than prompts.

Relational database vs semantic model

A relational database such as SQL Server stores and organizes data in structured tables. A semantic model sits above that storage as a business-friendly layer. It applies readable names, declared relationships, and predefined metrics, so time comparisons, ratios, and financial measures are written once and reused. Business users then build reports, or ask agents questions, without touching SQL. Storage is structure. A semantic model adds semantic understanding on top of metadata management.

Semantic model vs semantic layer

A Power BI semantic model is a semantic layer scoped to one tool, covering Power BI and the Microsoft services that read from it. Dedicated semantic layers such as the dbt Semantic Layer or Cube define metrics outside any single BI tool so many tools can share them. The trade-off shows up as soon as a second tool needs the same metric, which is where a Power BI model and a dedicated semantic layer diverge, and where a semantic layer and a data catalog stop being interchangeable.

---

What are the core contents of a Power BI semantic model?

Everything a semantic model knows lives in its model definition, which Microsoft describes through the TMSL model object and its text-based equivalent, TMDL. That definition holds:

• Tables, columns, and partitions: the structural core, ideally arranged as a star schema, with partitions defining how each table loads.
• Relationships: joins between table pairs, including filter direction and the security behavior each relationship applies.
• Data sources and shared expressions: connections to warehouses, lakehouses, files, and SaaS apps, plus the Power Query M expressions that shape incoming data.
• Measures, calculated columns, and KPIs: business logic such as year-over-year growth or gross margin, written in Data Analysis Expressions.
• Hierarchies and perspectives: drill paths like year, quarter, and month, plus scoped views that show a subset of the model to a given audience.
• Cultures and linguistic schema: translations and synonyms that let people and agents ask for the same field in different words.
• Roles: definitions carrying row-level and object-level security filters written in DAX.
• Descriptions and AI settings: table, column, and measure descriptions, AI instructions, and verified answers.

The model carries structure and calculation. It carries almost nothing about who owns a measure or whether its definition was contested, and both of those are metadata an AI agent needs.

---

How does a Power BI semantic model work?

Building and running a semantic model follows a repeatable lifecycle. The six steps below reflect how most enterprise BI teams work across Power BI Desktop and the Power BI service.

Step 1: Connect to sources and shape data

Model authors start in Power Query, connecting to warehouses, lakehouses, files, and SaaS apps before cleaning data with M expressions. Teams with existing enterprise warehouse investments can also connect live to Analysis Services models instead of importing data.

Step 2: Model relationships and business logic

Authors define relationships between tables and write DAX measures that encode business rules. Every report built on those definitions then returns the same answer. This is the point at which a metric becomes shared property, and where the systems of semantics holding it start to matter more than the tool it was written in.

Step 3: Choose a storage mode

Storage mode determines where data lives and how queries execute. Microsoft offers three classic options, plus Direct Lake for Fabric.

Import mode loads compressed data into memory with the VertiPaq engine. It suits fast, interactive reports on data that fits capacity. The trade-off is that data is only as current as the last refresh.

DirectQuery mode sends native queries to the source when users interact. It suits very large or near real-time data, and requires minimal memory to load the model. DAX is limited to functions the source can translate.

Composite mode mixes Import and DirectQuery, and can integrate several DirectQuery sources. You set Import, DirectQuery, or Dual per table, which suits blending historical and current data.

Direct Lake, available on Fabric, reads Delta tables in OneLake directly without importing or translating queries, and is the mode most relevant to teams already building on a lakehouse.

Step 4: Secure the model with roles

Authors define row-level security roles in Power BI Desktop, so a regional sales manager sees only their territory. Object-level security goes further, hiding entire tables or columns from specific roles. Those rules stop at the Power BI boundary. Once an agent reads the model from outside, role-based access control has to be redesigned at the context layer.

Step 5: Publish, refresh, and endorse

After publishing to a workspace, Import models refresh on schedule or on demand. Microsoft caps scheduled refresh at eight times a day on shared capacity and 48 times a day on Premium capacity.

Teams then promote or certify trusted models. Any user with write permission can promote a model, while only reviewers authorized by a Fabric administrator can certify one. The badge is the trust signal, and it is attached to the item in the service rather than written into the model definition, so anything reading the model over XMLA sees the measures but not the endorsement.

Step 6: Serve reports, Copilot, and AI agents

A single published model can serve many consumers at once:

• Reports and dashboards: Power BI reports connect live to the shared model without copying its data.
• Excel and developer tools: the XMLA endpoint lets Excel, SQL Server Management Studio, Tabular Editor, and DAX Studio query or manage models in Premium, Premium Per User, and Embedded workspaces.
• Copilot: Copilot in Power BI uses the model schema and its AI preparation settings to answer natural language questions, the same way any enterprise copilot works.
• AI agents: Microsoft’s remote Power BI MCP server lets agents query models in natural language, and the local server lets agents build and edit them. Both were in public preview as of September 2026. They speak the Model Context Protocol, which is worth understanding before deciding whether MCP or a plain API fits your integration.

---

When does a Power BI semantic model make sense?

A Power BI semantic model is the right foundation when most analytics consumption happens inside the Microsoft stack. It fits:

• Microsoft-centric analytics estates: teams running Fabric lakehouses, Azure SQL, and Power BI end to end.
• Managed self-service BI: a central BI team owns a small number of certified shared models, and analysts build reports on top.
• Copilot and conversational analytics in Power BI: teams rolling Copilot out to business users who expect conversational search over enterprise data.
• Migrating from Analysis Services: SQL Server or Azure Analysis Services tabular models move into Power BI on the same modeling concepts.

When does a semantic model alone fall short?

A standalone Power BI semantic model starts to strain in multi-tool environments:

• Several BI tools in use: DAX measures live in the Power BI engine, so other tools connect through XMLA or keep their own copy of the logic. Looker teams hit the same wall with LookML instead of a universal semantic layer.
• AI agents built outside Microsoft: agents on other frameworks need definitions, lineage, and ownership spanning more than one BI tool, which is where a semantic layer built for BI and one built for AI agents part ways.
• Metrics already defined upstream: teams defining metrics in dbt or the warehouse risk maintaining two versions of the same calculation, which is the practical difference between a semantic layer and a metrics layer.
• Lineage and business context live elsewhere: a semantic model does not store source-to-report lineage. Power BI’s lineage view and Microsoft Purview Unified Catalog track it separately, and neither carries the business context for AI an agent needs to interpret a number.

---

How Atlan approaches semantic layer governance

Most enterprises run more than one semantic layer. Finance defines revenue in Power BI, product analytics defines it in dbt, and a data science team queries the warehouse directly. Atlan treats each semantic model as one valuable source of business meaning, then connects it to the definitions, lineage, and policy held everywhere else. Teams routinely conflate a context layer, a data catalog and a semantic layer, and that confusion is why platform-native context layers fail once an estate crosses vendors.

Bring Power BI semantic models into the Enterprise Data Graph

Atlan’s Power BI connector catalogs workspaces, semantic models, tables, columns, measures, reports, and dashboards. Lineage runs source to report: Atlan parses Power Query M expressions to trace table-level and column-level lineage from Snowflake, Databricks, and BigQuery into Power BI tables, then downstream to reports. Those edges land in the Enterprise Data Graph alongside every other asset, and lineage parsed automatically from SQL survives a schema change in a way a hand-drawn diagram does not.

Connect definitions across semantic layers with Active Ontology

Power BI is rarely the only place metrics live, so Atlan also catalogs semantic assets from dbt, Cube, and the warehouse. Active Ontology links them through a shared model of glossary terms, domains, metrics, and relationships, aligned with the Open Semantic Interchange standard. Whether that shared model should be an ontology or a semantic layer is a real design decision, and ontology design for AI is where it gets made.

Build, test, and version context in Context Engineering Studio

Context Engineering Studio bootstraps a semantic layer from existing metadata, SQL queries, and BI dashboards, so teams avoid the blank page. Domain experts refine definitions in Bounded Context Spaces, where conflicting definitions from different teams get resolved deliberately rather than left to whichever dashboard the executive opened. The studio turns existing dashboards into evaluation suites that test whether an agent answers real business questions correctly, and evaluating context is a different exercise from testing data quality. Approved context ships as Context Repos with Git-like versioning, branching, and rollbacks.

Keep context current with Context Agents

Semantic models change constantly as authors add measures and rename columns. Context Agents generate and enrich descriptions, glossary terms, classifications, and suggested owners, so documentation keeps pace with each model instead of aging into tribal knowledge.

Serve governed context to every agent through MCP

The Atlan MCP Server works alongside Microsoft’s Power BI MCP servers. Power BI’s servers query and edit the semantic model itself. Atlan’s server gives MCP-compatible agents the surrounding context: certified definitions, lineage, ownership, and policy rules. That surrounding context is why AI agents need an enterprise context layer rather than a better connector.

---

Real stories from real customers building enterprise context layers with Atlan

---

Moving forward with semantic layers for your enterprise

Power BI semantic models remain one of the most practical ways to give reports, Copilot, and agents a consistent view of business logic inside the Microsoft stack. In-memory performance, certified shared models, and built-in security make them hard to replace for Power BI workloads.

The limits appear at the edges. Once definitions need to reach other BI tools, agents built outside Microsoft, or teams tracing lineage across systems, the model needs a broader foundation around it. Endorsement lives on the item rather than in the model, DAX logic stays in the engine, and lineage stops at the report.

A practical path starts small: certify a handful of shared models, document and test them for AI, then connect their definitions and lineage to a context layer every agent can read. The harder question, which no storage mode answers, is which definition wins when two teams disagree.

Book a demo

---

FAQs about Power BI semantic models

1. What is the difference between a Power BI dataset and a semantic model?

There is no functional difference. Microsoft renamed Power BI datasets to semantic models in November 2023 because dataset had become too generic across Microsoft Fabric. Some APIs and older documentation still use the word dataset for the same object.

2. Is a Power BI semantic model the same as a semantic layer?

A Power BI semantic model is a semantic layer scoped to Power BI and the Microsoft services that read from it. A dedicated semantic layer holds the same kinds of business logic independently of any single BI tool, so several tools and applications can share one definition.

3. Which storage mode should you use for a Power BI semantic model?

Import mode suits most models because it gives the fastest query performance and the full DAX function set. DirectQuery fits data too large to refresh practically or reports that need near real-time results. Direct Lake works for Fabric lakehouses built on Delta tables, and composite models help when some tables need freshness and others need speed.

4. Can multiple reports use one Power BI semantic model?

Yes. A shared semantic model can feed many reports across workspaces as long as report creators have Build permission on the model. Microsoft recommends this pattern, known as managed self-service BI, to keep model counts low and calculations consistent.

5. How big can a Power BI semantic model be?

The default limit is 1 GB per model. Premium Per User raises the ceiling to 100 GB, and Premium or Fabric capacities using the large semantic model storage format allow models up to the capacity memory limit. Import mode compresses heavily, so even a 1 GB model can hold several gigabytes of source data.

6. How do you prepare a Power BI semantic model for Copilot and AI agents?

Start with clear table and column names, a star schema, and a description on every important measure. Then use the Prep data for AI settings: an AI data schema to limit the fields Copilot considers, AI instructions to clarify business terms, and verified answers for common questions. Test with real user questions before marking the model approved for Copilot.

7. Can AI agents outside Microsoft query a Power BI semantic model?

Yes. Agents reach semantic models through the XMLA endpoint, the Power BI REST APIs, or the remote Power BI MCP server, which generates and runs DAX under the signed-in user permissions. For questions that span several systems, agents also need definitions, lineage and ownership from beyond Power BI.

---

Sources

1. Microsoft Learn | Semantic models in the Power BI service
2. Microsoft Learn | Datasets renamed to semantic models
3. Microsoft Learn | Semantic model modes in the Power BI service
4. Microsoft Learn | Endorsement: promote and certify content
5. Microsoft Learn | Semantic model connectivity with the XMLA endpoint
6. Microsoft Learn | Power BI MCP servers overview
7. Microsoft Learn | Row-level security in Fabric
8. Microsoft Learn | TMDL overview
9. Microsoft Learn | Prepare data for AI: verified answers
10. dbt Labs | Semantic layer vs text-to-SQL benchmark, 2026
11. Atlan Docs | What does Atlan crawl from Microsoft Power BI