Every Fabric pricing guide you read in 2026 lands on the same advice: pick the right F-SKU, mind the F64 threshold where Pro licences fold into the capacity, take the reservation discount once your workloads settle. It's all correct, and it's all about the day you buy. Almost none of it is about the eleven months afterwards, which is where the money actually goes.
Consumption is a commons
The thing Fabric changed isn't really the price. It's the shape. You've moved from buying named licences (essentially, a cost you could read off a spreadsheet) to buying a shared pool of Capacity Units that every workload draws from at once. Power BI refreshes, pipelines, notebooks, the lot, all pulling from the same engine.
A shared pool with no owner behaves exactly how you'd expect. Every team adds the pipeline it needs. Every analyst sets a refresh to hourly because hourly feels responsive. None of it is unreasonable on its own, and all of it lands on one meter that nobody is accountable for. When the resource is shared and the cost is invisible, consumption only goes one way...
Sizing up is the expensive reflex
The moment a capacity starts throttling, the instinct could be to just jump up an F-SKU. Sometimes that's right. Often it's paying to hide a problem. A flat, denormalised table that should have been modelled properly will burn capacity at any size — you've just bought a bigger engine to drag the same dead weight. The refresh running every fifteen minutes that feeds a report three people open weekly will keep running every fifteen minutes on the larger SKU too.
The Capacity Metrics app tells you which items are doing the burning. It's the single most useful and least opened tool in the stack. Before you size up, the discipline is to ask what's actually consuming the CUs and whether it should be - half the time the answer is an architecture decision somebody deferred, rather than any capacity shortfall.
Cost is an architecture decision
In a consumption model, cost stops being a procurement line and becomes an architecture property. How you model the data, how often you refresh, whether you copy data into OneLake or leave it where it is and shortcut to it, whether cold history sits on expensive storage forever - those are design choices, and every one of them shows up on the bill. You can't govern the spend without governing the design.
Which makes FinOps a governance function, not a finance one. Someone has to own the shared meter. Someone has to be allowed to ask the team why their refresh cadence tripled, and to say no to the third pipeline that does what two existing ones already do. Without that, the budget a controller signed off once drifts upward every quarter, and the first anyone hears of it is the renewal conversation.
Fabric's economics reward the things good data architecture rewarded anyway: model properly, refresh deliberately, don't keep what you don't need, don't copy what you can reference. The bill is just the new feedback signal telling you whether you did. Treat capacity as a shared resource with a named owner and a monthly look at the metrics, and the cost manages itself. Treat it as an engine you buy once and forget, and it will quietly become the most expensive thing in your data estate that nobody decided to spend.
