Capacity and cost optimization in Fabric

Install the Microsoft Fabric Capacity Metrics app before you do anything else. Without insight into which items consume capacity, every optimization is guesswork. The distribution is almost always skewed: a handful of workloads consume the lion's share.

One shared capacity means a heavy notebook experiment can slow down your executive reporting. At minimum two capacities (production and other) is the cheapest insurance there is; pause the non-production capacity outside working hours.

1. Refresh frequency: most semantic models refresh more often than anyone looks at them. Halve frequencies and wait for complaints, they rarely come.
2. Spark jobs: wrong cluster settings and non-compacted tables make jobs unnecessarily heavy. Starter pools and autoscale are a start, not an endpoint.
3. Direct Lake instead of import: every import refresh is double work (read, compress, copy). Direct Lake eliminates that for suitable models.
4. Real-time ambitions: the most expensive misunderstanding. Ask per dashboard which decision gets made faster because of it; usually the answer is "none".

Two things that steer every sizing discussion. Copilot in Fabric works from F2 (any paid SKU, not on trial), but note: Copilot consumption counts as a background job on your capacity and weighs relatively heavily on a small SKU. With intensive Copilot use, a split-capacity strategy with a separate capacity for Copilot is worth considering. And from F64 viewers may view Power BI content without a Pro license, provided they have the Viewer role and the content sits on that F64 capacity; with many users that is the big cost tipping point. Also: for stable production choose a capacity reservation of one or three years (considerably cheaper than pay-as-you-go; check the current difference on the Fabric pricing page) and keep dev and test on PAYG so you can pause outside office hours.

Fabric spreads peaks over time (smoothing and bursting). That makes the platform smooth, but it also masks over-consumption until it is too late. Throttling then kicks in in four phases, depending on how far ahead you have borrowed future consumption. Up to ten minutes, overage protection applies and you notice nothing. Beyond ten minutes, interactive operations get a twenty-second delay. Beyond an hour, interactive operations are rejected while background operations may still start. Beyond twenty-four hours every new request is rejected, interactive and background alike. Starting too small and constantly throttling is a classic mistake, as is structurally over-requesting and getting the bill back as delayed throttling. Our own rule of thumb, not a Microsoft standard: treat sustained load above eighty percent as an incident.

Discuss capacity consumption in design reviews, not only when the invoice arrives. The cheapest optimization is the workload you do not build, and the second cheapest is the same workload with an honest latency requirement.