Where Semantic Models Actually Live in Microsoft Fabric and Power BI

In what a semantic model actually is, we covered what belongs inside one: certified measures, relationships, naming, row-level security. That's the content question. Today's is the architecture question: where does this thing physically live in Microsoft's stack, and how does it relate to Fabric, OneLake, and the Power BI reports built on top of it.

Getting the contents of a semantic model right and still placing it in the wrong spot architecturally is a common, specific failure mode. It's worth understanding both halves separately.

Key Takeaways

• OneLake is Fabric's single, unified data store. Everything (lakehouses, warehouses, semantic models) reads from and writes to it in the same Delta table format (Microsoft Learn).
• Direct Lake mode lets a Power BI semantic model query Delta tables in OneLake directly, without importing or duplicating the data first (Microsoft Learn).
• Microsoft has formally renamed "Power BI dataset" to "Power BI semantic model," reflecting that this is the same governed layer across Power BI and Fabric, not two different things.
• The most common architecture mistake is treating each new report as a reason to spin up a new, separate semantic model instead of connecting to one shared model. Fabric doesn't prevent this by default; the discipline has to be deliberate.

The Fabric Stack in Plain Terms

Four layers, in order. Raw data sources (your CRM, ERP, product database, spreadsheets) land in OneLake, Fabric's single unified data store for all analytics data. Everything downstream (a lakehouse, a warehouse, a semantic model) reads from and writes to OneLake in the same underlying Delta table format, which is what makes it "one lake" instead of yet another set of disconnected copies, per Microsoft's own documentation.

On top of that sits the semantic model, the governed layer from Day 3. And on top of the semantic model sit however many Power BI reports need it, each one querying the same model instead of recreating its own version of the underlying logic.

This is a genuinely different architecture from the older pattern of importing a static copy of data into each individual Power BI file. Fabric's design intent is one shared data layer, one shared semantic layer, and many reports pulling from both.

Lakehouse or Warehouse: Does It Matter for the Semantic Model?

Fabric offers two different item types for the layer between OneLake and the semantic model: a lakehouse and a warehouse. A lakehouse is built around Spark-based engines and is comfortable with a mix of structured and less-structured data. A warehouse is built around a T-SQL engine and behaves closer to a traditional relational data warehouse. Teams sometimes treat this as a bigger decision than it needs to be for semantic modeling specifically.

From the semantic model's perspective, the distinction matters less than it seems, because both item types write their data into OneLake in the same Delta table format. A semantic model built on Direct Lake can read Delta tables that originated from a lakehouse or a warehouse without caring which one produced them. The choice between lakehouse and warehouse is real and worth making deliberately, but it should be driven by your team's engine preference and existing SQL versus Spark skill set, not by an assumption that only one of them supports a proper semantic model on top.

What Direct Lake Actually Changes

The mechanism worth understanding here is Direct Lake, a storage mode for Power BI semantic models built specifically for Fabric. Instead of importing and duplicating data into the model (the traditional approach), Direct Lake lets the semantic model query Delta-formatted tables in OneLake directly, in place, per Microsoft's own documentation.

Two things follow from that. First, there's no separate, aging copy of the data sitting inside the semantic model that can drift out of sync with the source, because there's no copy. Second, this is also why Microsoft formally renamed "Power BI dataset" to "Power BI semantic model": the old name implied a static extract, and Direct Lake models often aren't one. The rename reflects what the object actually is now, a governed logic layer over live data, not necessarily a snapshot.

None of this changes what belongs inside the model (Day 3's answer still holds). It changes how the model gets its data, and it removes one entire category of staleness problem that used to exist by default.

Import mode still has a place. A semantic model built for heavy, complex transformations, or one that needs to work fully offline from its source, may still be better served by importing and shaping the data first. Direct Lake is the default worth reaching for when the priority is fresh data with minimal duplication, not a rule that every model must follow regardless of its actual requirements.

The Common Architecture Mistake

Here's where teams undo the benefit of this design without realizing it. Fabric makes it just as easy to create a new semantic model per report as it does to reuse an existing one: open a lakehouse or warehouse, select "New semantic model," pick some tables, and a report builder has their own model in a few clicks. Nothing in the platform stops this by default.

Do that repeatedly across a team and you've quietly recreated Day 2's problem inside a modern architecture. Five report-specific semantic models means five places "Net Revenue" can be defined slightly differently, even though they're all technically built the same way, on the same underlying OneLake data. The technology changed. The failure mode didn't.

Picture a hypothetical, common pattern: a finance analyst builds a revenue-tracking report and creates a new semantic model to power it. Three months later, an operations analyst needs a similar revenue view for a different purpose and, not knowing the finance model exists or how to find it, builds a second one from the same underlying warehouse tables. Both models are technically correct. Neither analyst did anything wrong given what they could see. The organization now has two governed-sounding, professionally built semantic models quietly disagreeing with each other, which is a harder problem to untangle than the ungoverned reports from Day 2, because these ones look official.

The fix is procedural, not technical: before creating a new semantic model, the first question should be whether an existing one already covers this data domain. If it does, connect to it. If it genuinely doesn't (a new data domain nobody has modeled yet), that's when a new model is warranted, and it should be built with the intent of being the shared model for that domain going forward, not a one-off. A short, visible catalog of which semantic model owns which domain, even a simple shared document, prevents the scenario above more reliably than any platform setting.

How to Actually Architect This

In practice, this means organizing semantic models around business domains (sales, finance, product, operations), not around individual reports or individual report authors. Each domain gets one certified semantic model. Report builders connect to the domain model that covers their question rather than importing raw tables and starting from scratch.

When a report genuinely needs data from more than one domain, Power BI's composite models let a report combine multiple existing semantic models rather than forcing a single, ever-growing monolith or, worse, a fresh redundant copy of everything. The goal isn't one semantic model for the entire company. It's one semantic model per domain, reused deliberately, built and maintained through the same workflow Microsoft documents for creating a semantic model directly from a lakehouse or warehouse item (Microsoft Learn).

Three practical signals tend to confirm a domain boundary is drawn correctly. The people who would argue about a given metric's definition all sit inside that one domain, not spread across two. The tables the model depends on come from a coherent, related set of source systems, not an arbitrary mix. And a new report request for that subject area can almost always be answered by connecting to the existing model rather than proposing a new one. When a team finds itself justifying a new semantic model every few weeks for what's plausibly the same subject area, that's usually a sign the domain boundaries were never actually agreed on, not a sign that Fabric needs more models.

Where This Fits

At ClarusIQ, this is where Data Foundation work and Power BI Reporting work meet directly: once a semantic model's contents are right (Day 3), the architecture question is whether it's organized by domain, built on Direct Lake against OneLake where it makes sense, and actually being reused instead of quietly forked per report. That review usually starts with a simple inventory: how many semantic models currently exist in the tenant, which business domain each one is supposed to cover, and how much overlap exists between models that were never meant to compete with each other.

Most organizations that have been on Fabric or Power BI for more than a year are surprised by that inventory. It's rarely zero duplicates, and it's rarely deliberate duplication either. It's the natural result of a platform that makes creating a new model easy and reusing an existing one only slightly easier, without a habit already in place to default toward reuse.

If you want a second set of eyes on how your current Fabric or Power BI environment is architected, get a Fabric and Power BI architecture review.

Next in this series: once this architecture is solid, it becomes the exact foundation Copilot and natural-language AI features query, and why that dependency runs in one direction only.