The single most common question I get asked about Microsoft Fabric has nothing to do with lakehouses or Copilot or Direct Lake. It's this: "We've had it a few months. Why is the bill doing that?" Usually asked by someone who signed off on the capacity and is now being asked, upward, to explain a number they can't yet read.
So this is the post I wish I could hand people before they buy, not after. No pricing-page screenshots that go stale in a quarter — those change and I don't want to be quoted a wrong figure. Instead, the mental model: what you're actually paying for, why it behaves the way it does, and how to plan it so the invoice is boring. Boring is the goal. In cost management, boring is a triumph.
What a Capacity Unit actually is
Fabric doesn't charge you per query, per report, or per user the way a lot of cloud services do. It charges you for a capacity — a fixed pool of compute you rent — and everything you do in Fabric draws from that one pool. The unit that pool is measured in is the Capacity Unit, or CU. Think of a CU as the single currency of Fabric: data pipelines spend it, semantic model queries spend it, notebooks and Spark jobs spend it, a Power BI report refresh spends it. Warehouse, lakehouse, dataflow, Copilot — all of it, one wallet.
You buy that wallet in fixed sizes called F SKUs, and the naming is refreshingly honest — the number is the CU count:
| SKU | Capacity Units | Rough shape of workload it suits |
|---|---|---|
| F2 | 2 | A single small workload, dev/test, kicking the tyres |
| F8 | 8 | A modest team with a handful of models and pipelines |
| F16 | 16 | A department running real, daily analytics |
| F64 | 64 | Enterprise workload — and the threshold where free Power BI report viewing for your org kicks in |
| F128+ | 128 and up | Large, multi-domain estates |
Two things to notice immediately. First, the SKUs roughly double as you climb, so "size up" is a big step, not a nudge. Second, F64 is a genuine cliff edge, not just a bigger number: at F64 and above, people across your organisation can view Power BI content without each needing a paid per-user licence. For an estate with a lot of read-only report consumers, that one threshold can flip the entire licensing maths — which is exactly the kind of thing that belongs in the business case, not discovered afterwards.
Smoothing and bursting: the clever bit
If Fabric simply cut you off the instant your workload exceeded your CUs, capacity planning would be miserable — you'd have to size for your single worst minute of the month and pay for that headroom the other 43,199 minutes. Fabric doesn't do that, and understanding how it avoids it is most of what "reading the bill" means.
- Bursting lets a workload temporarily consume far more CUs than your SKU nominally provides, so a heavy job finishes fast instead of crawling along inside your baseline. Your F16 can briefly behave like something much larger to get a spike done.
- Smoothing is the accounting trick that makes bursting affordable. Instead of billing that spike the instant it happens, Fabric spreads the CU cost of your work forward over time — over minutes for interactive work, over a longer window for scheduled background jobs. A big overnight batch doesn't have to be paid for in the ten minutes it ran; its cost is averaged out.
Put together, the model is forgiving of peaky workloads and unforgiving of sustained ones. You can spike hard and often, as long as the smoothed average sits under your capacity. What you can't do is run hot continuously, because then there's nothing quiet to smooth into.
Throttling: what "running out" feels like
So what happens when you genuinely overrun — when the smoothed debt keeps climbing and never gets a chance to settle? You get throttling, and it arrives in stages rather than as a wall. First, interactive requests get a small delay. Push further and the delays get longer. Push further still and background operations start getting rejected until the capacity catches its breath.
The important insight for planning: throttling is a signal of sustained over-consumption, not a one-off spike. If your capacity is throttling, the fix is almost never "panic-buy the next SKU up." It's to open the Fabric Capacity Metrics app — the free report Microsoft ships for exactly this — and find out what is eating the pool. Nine times out of ten it's a specific offender: a semantic model refreshing far more often than anyone needs, a pipeline reprocessing all of history every night out of habit, one runaway notebook. Sizing up to hide a wasteful workload is the Fabric equivalent of buying a bigger suitcase instead of packing less.
Pause, resume, and reserve: the levers that actually move the bill
Because capacity is compute you rent, the biggest savings come from not renting it when you don't need it, and committing when you do.
- Pause and resume. An F SKU can be paused, and while it's paused you're not billed for its compute. A dev or test capacity that only needs to be alive during working hours is a standing, easy win — automate the pause on a schedule and you stop paying for nights and weekends you were never using.
- Pay-as-you-go versus reserved. Run a capacity on-demand and you pay a premium for the flexibility. Reserve it for a longer term and the rate drops substantially. The trick is to reserve only your stable baseline — the capacity you know you'll run continuously — and keep genuinely spiky or seasonal workloads on pay-as-you-go, so you're never locked into paying for peak all year round.
That split — reserve the floor, flex the peaks — is the single most useful capacity-planning habit I know, and it's invisible unless you've decided to look for it.
The Fabric bill is not a mystery. It's a mirror. A surprising invoice is almost always a workload nobody was watching, reflected back at you with a price tag.
So what are CUs actually worth?
Here's the honest verdict. The CU model is genuinely good if you treat capacity as something you actively manage, and genuinely punishing if you treat it as a switch you flip once and forget. Its great virtue is that it turns a sprawling, unpredictable set of workloads into one number you can watch, forecast, and defend to a finance director. Its trap is that the same single-pool simplicity hides which workload is responsible for the number — so without the discipline of reading the metrics app, you get one big bill and no idea which of your teams earned it.
My advice to anyone sizing Fabric: don't start from the SKU. Start from the workload. Map what you'll actually run, identify your steady baseline versus your spikes, decide what genuinely needs to be always-on, and only then pick a capacity — with a deliberate plan to pause what you can and reserve what's stable. Do that and CUs are a fair, flexible deal. Skip it and you'll spend the year explaining an invoice instead of planning around it. The maths isn't hard. It just has to be done before the surprise, not after.