Microsoft Fabric Is Not What You Think It Is
After a year of building production workloads on Fabric, I think most of the discourse about it — both the cheerleading and the skepticism — is missing the actual story. Here's what Fabric is really good at, what it isn't, and how to decide.
I have spent most of the last year inside Microsoft Fabric, building production workloads — not demos, not proofs of concept, but real lakehouses serving real business users with real consequences if the numbers are wrong. I want to write down what I have actually learned, because the conversation about Fabric on LinkedIn and in technical blogs feels increasingly disconnected from the experience of running it.
There is a cheerleader camp that says Fabric is the future of analytics, a unified platform that will replace your warehouse, your lake, your ETL tool, your reporting layer, and possibly your toaster. There is a skeptic camp that says Fabric is a marketing rebrand of services that already existed, with capacity-based licensing that punishes you for actually using it. Both camps are partly right. Neither is telling the story I think practitioners need.
What Fabric actually is, in one sentence
Fabric is the answer to a specific question Microsoft asked itself: how do we make Power BI’s semantic layer the gravitational center of a customer’s data estate, instead of one of many endpoints?
Read that again. Almost everything that is good about Fabric, and almost everything that is awkward about it, comes from this framing. The OneLake idea, the Direct Lake mode, the unified workspace concept, the way Notebooks and Pipelines and Warehouses all share storage — these are all in service of getting your data into a place where Power BI can query it without copying it, with the semantic model as the consumer-facing surface.
This is the actual product strategy. The marketing material wraps it in unification language because “unification” tests well in surveys, but if you read Fabric as “Power BI grew a lakehouse,” you will make better architectural decisions than if you read it as a Snowflake competitor.
Where Fabric is genuinely good
Three things are real and worth taking seriously.
Direct Lake mode is the feature. If you have not used Direct Lake, the elevator pitch sounds incremental — “your Power BI dataset queries Parquet files in OneLake without import or DirectQuery.” The actual experience is qualitatively different from anything I have used in twenty years of BI. You get the performance of import mode, the freshness of DirectQuery, and the storage economics of a lakehouse, with no copy step. For workloads where data changes daily and reports query large fact tables, this is a genuine breakthrough. I would not give it up.
Workspace-as-environment is the right primitive. Fabric workspaces unify what used to be three or four scattered concepts in a typical Microsoft data stack. Permissions, deployment pipelines, capacity attribution, and lineage all live in one place. Coming from environments where the analyst’s reality was scattered across Azure subscriptions, Synapse workspaces, Power BI tenants, and a Databricks console, the consolidation is not aesthetic — it is operational. Fewer places where things can go wrong.
The semantic-link / SemPy story is underrated. Being able to script against Power BI semantic models from a Notebook, evaluate measures, validate KPIs against source systems, and produce automated regression reports — this is the kind of capability that BI engineers have wanted for fifteen years and never quite had. I have used it to build automated KPI validation harnesses that catch broken measures before they reach the executive layer, which is the kind of quiet infrastructure work that pays for itself in averted incidents.
Where Fabric will hurt you
I want to be honest about the parts that have caused me actual pain in production.
Capacity is a sharp edge. F-SKU capacity is shared across every workload in the tenant — Notebooks, Pipelines, semantic models, even Eventstream. A heavy Notebook job at the wrong time can throttle interactive Power BI queries for hundreds of business users. You need to think about capacity allocation the way you used to think about Spark cluster sizing, except the consequences are visible to executives. Plan accordingly. Get comfortable with the capacity metrics app.
The XMLA/semantic-link tooling is not always stable. I have hit catalog binding errors, identity propagation issues, and intermittent failures in SemPy that required workarounds nobody was going to find on Stack Overflow. The platform is improving fast — and the improvements are visible release-to-release — but if you are coming from a mature tool ecosystem, you should expect to file support tickets and wait.
Direct Lake is not a free lunch. It works beautifully when your fact tables are tidy Delta with reasonable partitioning. It degrades into DirectQuery fallback in conditions you do not always control, at which point performance becomes unpredictable. The fall-back is automatic, which sounds nice and is actually a problem — you can ship a report that works fine in dev and quietly degrades in prod when row counts cross a threshold. Monitor it.
Service Principal vs. Workspace Managed Identity is a decision you must make consciously. The defaults are not always what you want, particularly for Notebook-based workflows that need to write back to lakehouses owned by other workspaces. Spending an afternoon mapping out your identity model up front will save you a week of debugging later.
How I would actually decide
If you are evaluating Fabric and you want a heuristic that I trust, it is this:
Fabric is a strong choice when Power BI is already your reporting layer of record and you want the storage and compute layer to be cheap, simple, and tightly coupled to it. Fabric is a weak choice when your analytics estate is genuinely heterogeneous — multiple BI tools, multiple cloud providers, real polyglot needs — and you would be using Fabric only for the storage layer.
There is no shame in continuing to run Snowflake or Databricks if those tools are doing their job. The Fabric proposition is strongest when you can collapse the distance between storage and the semantic layer, because that is the distance Direct Lake closes. If you cannot collapse that distance — if your reporting layer is going to be Tableau, or your storage has to live in Snowflake for governance reasons — then much of what makes Fabric distinctive evaporates, and you are left with a perfectly competent but unexceptional set of services priced by capacity.
The thing I would tell a CIO
If a CIO asked me — and a couple have — whether Fabric is the right bet, I would not answer in terms of features. I would ask what the ten-year direction of their analytics organization looks like.
If the answer is “fewer tools, deeper integration with Microsoft, executives consuming via Power BI, our analysts mostly working in Notebooks and SQL” — Fabric is a strong bet. Lean in. Build the platform team. Set up capacity governance early.
If the answer is “best-of-breed for each layer, multiple BI tools, polyglot data science, cloud-agnostic” — Fabric is going to be a square peg in a round hole. There are better tools for each individual layer. Microsoft is not going to make Fabric the right answer for your shape.
The mistake I see most often is treating this as a tooling decision when it is actually a strategic one. Fabric rewards commitment. It punishes hedging. Go in clear-eyed about which posture you are taking.
If you are mid-way through a Fabric evaluation and want a sounding board, my contact form is open. I am not in the business of selling implementations — I am in the business of making sure the implementation is the right call before anyone signs anything.