What is Microsoft Fabric? A Manufacturer’s Guide

A mid-market manufacturer has Power BI, an ERP, a scheduled refresh pulling a nightly extract onto a file share, an SSIS package running on a server nobody wants to reboot, and a tabular cube built by a contractor who left in 2019. Production reporting works, more or less, as long as you do not ask it anything new.

Then someone — an account manager, a reseller, a board member who read something — says the answer is Microsoft Fabric. Six weeks later there is a proposal on the desk with an F64 line item and no statement of what gets switched off in return. This article addresses that gap: not the product definition, but what Fabric replaces in an estate you already paid for, what it does not touch, and whether a manufacturer with one ERP and eleven Power BI reports should be buying it this year at all.

Microsoft Fabric is a software-as-a-service analytics platform that unifies previously separate Microsoft products — Power BI, Data Factory, data warehousing, Spark data engineering, data science, real-time analytics and databases — into one product with one storage layer called OneLake and one purchased compute pool called a capacity. You buy compute once, not per service.

The critical word is unifies. Before Fabric, a manufacturer building operational analytics on Microsoft provisioned each piece separately: Azure Data Factory for pipelines, an ADLS Gen2 account for files, a Synapse dedicated SQL pool or SQL Server for the warehouse, Azure Analysis Services or SSAS for the model, Power BI Premium for distribution. Five products, five bills, five sets of permissions, and data copied between each one.

Fabric collapses that into workloads inside a single SaaS tenant, all reading and writing to the same place. As Microsoft puts it: all Fabric analytics engines work with data directly in OneLake, so you do not need to copy data to use it with another engine.

Here is the mapping that usually ends the confusion in the room. It is deliberately framed around what you already own.

OneLake is a single logical data lake provisioned automatically with every Fabric tenant. There is exactly one per tenant, it cannot be deleted or duplicated, it stores tables in the open Delta Parquet and Iceberg formats, and every Fabric engine reads it directly. That removes the copy-per-tool tax that made previous Microsoft data estates expensive to run.

In a typical pre-Fabric estate the same production order table exists in the ERP, again in staging, again in the warehouse, again in the cube, and again inside a Power BI import model — five copies, five refresh windows, five chances for the numbers to disagree. Two features do most of the work. Shortcuts reference data held elsewhere so you point at existing data rather than copying it — for a manufacturer with an ADLS Gen2 lake, often the honest first step. Mirroring continuously replicates a source database into OneLake as Delta tables, with one free terabyte of mirroring storage per capacity unit purchased.

One commercial detail that catches finance teams out: OneLake storage is billed separately from capacity units, pay-as-you-go per GB. Capacity buys compute; storage is its own line.

Fabric is licensed as a capacity — a pool of compute measured in capacity units, purchased as an F SKU from F2 (2 CUs) through F2048. F capacities are bought through Azure and billed per second with no commitment, or reserved yearly at a lower rate. Every workload in the tenant draws from that same pool, and individual Power BI licences sit on top. Four things worth understanding before you sign:

• One pool, shared by everything. A Spark notebook rebuilding two years of history, a Dataflow refresh, a Copilot prompt and the CFO opening a report all draw on the same units — the strength of the model and its main operational risk.
• You can pause it. F capacity supports pause and resume; billing stops when paused, and so does access — which suits development capacities, not production.
• The F64 threshold is the biggest cost cliff. On F64 or larger, a user with the viewer role can read Power BI content with only a Free licence. Below F64, every viewer needs Pro, PPU or a trial. For 300 report-consuming staff, that threshold decides the commercial case on its own.
• Copilot needs F2 or higher. Access to the prebuilt Azure OpenAI Service, including Copilot in Fabric, requires an F2 or higher SKU, and consumes capacity like any other workload.

Do not guess at sizing — the F64 viewer threshold and Direct Lake guardrails together decide more of the bill than the headline SKU price.

Power BI is now a workload inside Fabric rather than a separate product, so a manufacturer already on Power BI Premium is partly on Fabric already. What changes is everything beneath the report: where data lands, how it is modelled, who governs it, and whether a question that crosses two source systems takes three days or three minutes.

Three differences a manufacturer will feel. The extract layer disappears — mirroring replicates the source continuously, and Direct Lake serves the model from those Delta tables without a full refresh. Cross-system questions become answerable — "which supplier's lateness caused this month's line stoppages?" needs purchase order history and production confirmations in one model, which is a data platform problem rather than a Power BI problem, and the actual reason to buy Fabric. And governance stops being a spreadsheet — Microsoft Purview integrates with Fabric for catalogue, sensitivity labels, DLP and audit, though whether your organisation will operate it is a separate question.

Fabric does not replace your ERP, MES or WMS. It is an analytical platform — production orders still originate in SAP S/4HANA, Business Central, Epicor or NetSuite. It does not fix master data: if your item master differs between ERP, WMS and the planning spreadsheet, Fabric will join them incorrectly at speed and with excellent visuals. This single issue causes more overrun on mid-market platform programmes than every technical factor combined.

It does not make on-premises data disappear — plant systems behind a firewall still need a gateway or edge hop. Small capacities carry real modelling limits: on F2 to F8 the documented Direct Lake ceilings are 300 million rows, a 10 GB model size and 3 GB of memory, and Direct Lake falls back to DirectQuery when it cannot read a Delta table directly. The AI layer has boundaries too — the Fabric data agent is read-only, English only, does not read PDFs, and returns a maximum of 25 rows by 25 columns. And a licence swap is not a transformation: buying an F64 and reassigning your workspaces takes an afternoon and changes nothing operationally. The value comes from the modelling work underneath — dimensions, grain, definitions, ownership — which is unglamorous, takes weeks, and belongs to the business rather than IT.

Adopt now if two or more are true:

• Your Power BI Premium P SKU is approaching term end and cannot be renewed
• Three or more source systems need joining — ERP plus MES plus WMS, or multiple plants on different ERPs
• You are carrying an SSIS or SSAS estate that needs a home and a maintainer
• A named operational decision is made monthly today and should be made weekly
• Somebody, internal or fractional, will own the model after go-live

Do not adopt yet if these describe you: one ERP, under a dozen reports, one analyst, and no decision waiting on faster data — Power BI Pro with a well-built model is the honest answer, and Fabric will cost more for the same output. You are mid-way through an ERP migration; wait for the source to settle. Your real problem is OEE on a whiteboard or item codes that differ by plant; fix capture first. Or the only driver is a Copilot demo somebody saw — AI on a broken data model produces confidently wrong answers faster.

Seven questions to answer this week, before anyone builds or buys:

• How many named users only ever view reports? Above ~50, price the F64 free-viewing threshold against per-user Pro first
• When does your Power BI Premium term end, and can it be renewed?
• What is running your data movement today — SSIS, ADF, manual exports — and who maintains it?
• Is your ERP database a mirroring-supported source, or does it need pipelines?
• Can you produce one reconciled list of items and locations across ERP, WMS and planning today?
• Which single decision would change if the answer arrived weekly instead of monthly, and who makes it?
• Who owns the model six months after go-live?

If question six has no answer, stop — the platform will be an expensive reporting layer. If question five has no answer, budget for master data work before platform work; the sequencing is not optional. We build these estates on Microsoft Fabric, OneLake and Power BI — and if the honest read is that you should not buy Fabric this year, we will say so.