How to size Microsoft Fabric capacity without blowing the budget

Capacity is not a server: it is a budget per second

The first misconception we see in Fabric projects is treating capacity like a virtual machine. It isn't. An F SKU is a pool of compute units consumed per operation — every dataset refresh, DAX query, notebook and pipeline draws from that pool.

The practical consequence is that the bottleneck rarely sits where you expect. A single badly written dataflow running hourly can cost more capacity than hundreds of users opening reports. Before increasing the SKU, you need to know who is consuming.

The three consumers that almost always explain the bill

In nearly every environment we audit, consumption concentrates in three places. First, full refreshes of large models that could be incremental — reprocessing five years of history every night is the most common waste and the easiest to fix.

Second, transformation happening in the wrong place: Power Query solving what should be solved in the lakehouse or warehouse, repeated on every load. Third, reports with DAX measures that scan entire fact tables on each interaction, multiplying cost by the number of users.

Once those three are addressed, environments often fit back into the SKU already contracted — with no license change at all.

Smoothing and throttling: peaks matter more than averages

Fabric spreads consumption over time (smoothing), which absorbs short peaks. But once accumulated debt crosses the limit, throttling starts: operations queue and users feel slowness while nothing is technically 'down'.

That is why watching average utilization is misleading. What matters is the peak pattern — usually concentrated in the refresh window — and the overlap between automated loads and human working hours. Spreading refreshes across the day often solves more than doubling capacity.

A four-step decision path

Before touching the SKU, follow this order: (1) inventory the environment and find out what exists, who owns it and what nobody opens; (2) measure consumption per item and identify the top five; (3) optimize those top consumers — incremental refresh, transformation in the right layer, DAX review; (4) only then resize, based on data rather than impression.

Environments with scheduled pauses (development and staging outside business hours) and workspaces separated by criticality tend to keep cost predictable throughout the year. That continuous monitoring is exactly what we automated in FabricBoard.