What a semantic model actually is#
A semantic model is the container of modeled data that Power BI reports, dashboards, and apps are built on — the concept formerly called a "dataset." A single model can combine data from more than one source [S1]. Apart from streaming models, every semantic model is built on Analysis Services tabular modeling technology [S2]. Models can originate several ways: publishing from Power BI Desktop, uploading an Excel workbook or CSV, connecting to an externally hosted Analysis Services model, or creating push/streaming models through service APIs [S2].
How a model stores its data#
Power BI Desktop supports three storage modes — Import, DirectQuery, and Composite — distinguished by whether data is copied into the model or left in the source at query time [S2]. Import serves a snapshot needing scheduled or on-demand refresh to stay current; DirectQuery forwards every query to the source, so results always reflect live data. Both need an on-premises gateway when the source isn't reachable over the internet [S2]. A fourth mode, Direct Lake, reads Delta tables straight out of OneLake with no copy step; once built, it's consumed exactly like any other model — reports, explorations, and DAX queries need no special handling [S3].
Models hold data in a highly compressed in-memory cache for fast queries; without the large storage format, the default size limit is 1 GB [S4]. Enabling that format raises the ceiling to the size of the Fabric capacity itself (or an admin-set maximum), on Fabric F, Premium P, Embedded A, and Premium Per User [S4].
A worked example#
A team publishes a Power BI Desktop model to the service. A colleague live-connects with Build permission and starts a new report — live-connecting is distinct from live-editing, so authoring the report doesn't change the model, and the colleague can add report-level measures that exist only in their own report [S3]. Later, a lakehouse in the same workspace gets no automatic default semantic model — since September 5, 2025 Fabric stopped auto-creating one on lakehouse creation — so the team builds theirs deliberately [S5].
Shaping the model well#
Whether a table behaves as a dimension or fact table is determined entirely by relationship cardinality, not any explicit property — the "one" side of a one-to-many relationship is always the dimension. A well-structured model keeps dimension and fact roles separate, with fact tables loading at one consistent grain [S6].
What goes wrong#
- Assuming refresh keeps Import data current in real time. Only DirectQuery reflects live source data [S2].
- Editing a live-connected model from a report. Changing gateway or connection settings requires ownership; non-owners see it read-only [S3].
- Ignoring the 1 GB default size ceiling. Hitting it without the large storage format silently blocks growth [S4].
- Mixing dimension and fact roles in one table. This breaks the cardinality-driven structure Power BI relies on [S6].