Microsoft Fabric Pricing Explained: Capacity Units, SKUs and Real Costs

Microsoft documents Fabric pricing thoroughly. You are buying a rate of compute, drawn down by every workload in the tenant, averaged across time windows, with several meters running alongside it that the capacity does not cover.

This article explains those mechanics. It does not estimate what your programme will cost, and it does not tell you which SKU to buy. I have quoted no list prices — Fabric pricing is regional and moves. Every mechanic below is verified against Microsoft Learn; price it against the Fabric SKU estimator and the Azure calculator for your own region and currency.

A capacity unit (CU) is Fabric's unit of compute power — a rate, not a quantity. An F64 provides 64 CUs continuously, which the platform evaluates as a budget of 1,920 CU seconds in each 30-second window. That window is the mechanical detail most explanations skip: Fabric divides the day into 2,880 timepoints of 30 seconds each, and at each one your capacity has a budget equal to its CU count times 30, from which every operation — a Spark notebook, a Dataflow refresh, a Power BI query, a Copilot prompt, a OneLake write — consumes CU seconds.

A CU is therefore not a seat and not a gigabyte. It is closer to a leased motorway lane: the right to move a certain volume of traffic per second, shared by everything in the tenant. Commercially, that decouples cost from headcount — two hundred report viewers cost the same in capacity terms as twenty, if they run the same queries. Cost is driven by workload — refresh frequency, data volume, model size, notebook runtime — making capacity an engineering variable, not an HR one.

Fabric F SKUs are named for their capacity unit count and double at each step: F2 (2 CUs), F4, F8, F16, F32, F64, F128, F256, F512, F1024 and F2048, with F4096 and F8192 in the capacity planning docs. The ladder is linear in compute — doubling the SKU doubles the compute rate — and there is no volume discount built into the ladder itself; that is the reservation's job.

Three practical consequences. You can move up and down it — F capacities are scaled like any other Azure resource, so an undersized capacity is not a sunk cost unless you have reserved it. The steps are coarse at the bottom — for a mid-market industrial business with one ERP, a WMS and a plant historian, the honest sizing conversation usually lands between F8 and F64, an eightfold bracket, which is why the estimator asks for compressed data size, batch cycle count and table count rather than user numbers. And one rung has commercial consequences unrelated to compute: F64 is where Power BI viewer licensing changes.

F capacities are billed through Azure per second with no commitment and a one-minute minimum, or reserved for one or three years at a lower rate. A reservation is purchased in one-CU increments, applied hourly, scoped to a region, and matched automatically to running capacity. The trade-off is sharper than a normal software commitment, for two documented reasons. Unused reservation is lost hourly, not annually — reserve 64 CUs and run 32, and the other 32 are gone for that hour, with no annual true-up. And the reservation covers compute only — not storage or networking, so a finance model treating the reservation as "the Fabric bill" will be wrong by however much OneLake storage and transfer you accrue.

The pattern that works: run pay-as-you-go for the first two to three months of production, watch the Capacity Metrics app, then reserve only the floor you are confident you consume every hour and leave the peak on pay-as-you-go.

A capacity buys compute. This is the table to put in front of a finance approver:

Two deserve emphasis. Mirroring's free allowance is generous — 1 TB per CU, so an F64 carries 64 TB — but it is tied to a running capacity. And capacity overage at 3× pay-as-you-go is priced to be a circuit breaker, not a capacity plan.

Fabric lets operations burst above the provisioned CU rate to finish faster, then smooths the resulting consumption — interactive operations over 5 to 64 minutes, background operations over a full 24-hour period. This is good engineering and confusing accounting. Bursting means a Spark job rebuilding two years of history can temporarily use more compute than the SKU provides, finishing in twenty minutes rather than three hours — you are not blocked at the ceiling. Smoothing is how you pay for it: rather than charging the burst against one timepoint and throttling instantly, Fabric averages the consumption forward.

The consequence: a nightly ERP load running at 02:00 is still occupying capacity budget at 14:00 when the sales team opens their reports. Contention is not a function of concurrent users at a moment in time, but of everything the estate did in the preceding day. That is the most common reason a capacity which looked fine in testing starts delaying reports in week six of production. It also means you cannot attribute cost to a department by watching the clock.

Fabric does not fail over or auto-bill by default — it throttles, in documented stages:

Excess consumption becomes carryforward CUs, burnt down by unused capacity in later timepoints, and throttling continues until the carryforward is paid off — so one unbounded Spark job on a Friday night can degrade Monday morning. Three controls exist: surge protection (a background-rejection threshold plus per-workspace limits, with workspaces tagged Mission Critical or Blocked), capacity overage (pays off the excess at 3× rather than throttling), and scaling the SKU. For an operations estate the design decision is which workspaces are Mission Critical — if the plant's shift-handover report and an analyst's exploratory notebook share a capacity with no limits, the notebook wins by accident.

On an F64 capacity or larger, users with only a Power BI Free licence and the workspace viewer role can view Power BI content. Below F64, every viewer needs Pro, PPU or a trial. For mid-market industrials this is usually the decision, not the compute sizing. A packaging business with 400 read-only staff faces a straight comparison: 400 Pro licences on an F8, or an F64 with 400 Free licences plus a handful of Pro for the authors. The crossover frequently lands well below the compute the business actually needs — you buy F64 for the licence rule and get the compute as a by-product.

Two traps: Free licences let users create non-Power BI Fabric items on an F capacity but not Power BI items outside My Workspace; and PPU is not a route to Fabric — it does not provision a capacity or enable non-Power BI items. Copilot adds a wrinkle: a Fabric Copilot capacity lets an administrator centralise Copilot billing on one designated capacity, minimum F2, in the tenant's home region.

F SKU capacities can be paused and resumed, and billing stops while paused — but content on the capacity becomes unavailable, and on pausing, any remaining cumulative overages and smoothed operations are summed and added to the Azure bill immediately. Pausing works for development and test capacities, and for batch-only estates in a single time zone. It does not work for a production capacity serving a 24-hour plant or three countries, because paused means unavailable, not slow.

Three things people miss: mirroring stops entirely when paused, and you begin paying OneLake storage for mirrored data that was free while running; the smoothed backlog is settled at the moment of pause, so pausing at the end of a heavy day does not avoid that day's cost; and a reservation keeps billing regardless — pause a reserved capacity and you have paused the workload, not the commitment. One legitimate emergency use: pausing a throttled capacity ends the throttling immediately.

The model prices compute honestly but hides four things from a purchase approver. The estimator is a preview tool fed by your guesses — compressed data size, batch cycles, table counts — every one an estimate before you have built anything; treat its output as a bracket and re-size after 60 days of real telemetry. Capacity cost is a consequence of modelling quality — a star schema at the correct grain with an incrementally refreshed fact table consumes a fraction of a wide flat table refreshed in full every hour, so two businesses with identical data volumes can sit three SKU rungs apart, and nobody quotes that variance at purchase time.

The capacity bill is not the programme cost — capacity is often the smallest line, below data engineering, semantic modelling, master data reconciliation and the internal time to define OTIF or OEE consistently. Chargeback is not free — Fabric bills the tenant, not the department, so allocating cost requires workspace design and someone reading the Capacity Metrics app monthly. And throttling is a business risk, not an IT one — the gap between interactive delay and interactive rejection is the gap between a slow morning and a plant management team without their shift report.

Five questions to answer this week, before the purchase request goes back up the chain:

• How many people only view reports? If above ~50, model F64 with Free viewer licences against the Pro-licence alternative before discussing compute at all
• What is your heaviest scheduled job, and when does it run? Because of 24-hour smoothing, it competes with tomorrow's report traffic, not tonight's
• Which workspaces are Mission Critical? Name them now, and set surge protection limits on the rest
• Who reads the Capacity Metrics app, and monthly or never? An unowned capacity drifts in exactly one direction
• What is your OneLake retention policy? Soft-deleted data bills at the same rate as active data

Answer one and two and you can defend a SKU choice. Answer three to five and you can still defend it in twelve months. We size and run these capacities as part of building the estate — and we will tell you when an F8 is enough, and when the honest answer is that you are buying F64 for a licensing rule rather than for compute.