In Short: Which F SKU Do You Need?
Not the one your data volume suggests. Fabric capacity is consumed by activity, not storage: how often you refresh, how many people query at once, and how efficiently the workloads are written. Two organisations with identical data sizes routinely need SKUs two tiers apart. The reliable method is to run real workloads on pay-as-you-go for two to four weeks, read the metrics, then reserve what the data supports.
Why Data Volume Is the Wrong Starting Point
The first question most people ask is "how much data do we have?", because that is how on-premises servers were sized. It is close to irrelevant here.
Storage in OneLake is billed separately and cheaply. What draws on capacity is work: a pipeline running, a notebook executing, a warehouse query resolving, a report rendering. A ten-terabyte archive that nobody touches consumes almost nothing. A fifty-gigabyte model refreshed every fifteen minutes and queried by two hundred people all morning consumes a great deal.
So the sizing question is really: how much work will happen, and when?
What Actually Drives Consumption
Four things, in rough order of impact:
Refresh frequency and method. A full daily refresh of a large model is expensive. The same model on incremental refresh is a fraction of it. Moving from four-hourly to hourly refresh does not add 25% - it can add considerably more, because each run carries fixed overhead.
Query concurrency. Not how many users exist, but how many are active simultaneously. Two hundred people who open a dashboard once a week are a lighter load than thirty analysts querying continuously from nine to eleven each morning. Concurrency peaks size your capacity; averages mislead.
Workload efficiency. This is the variable nobody budgets for and the one that most often decides whether an F16 is comfortable or throttled. An inefficient semantic model, a query scanning far more than it needs, or a pipeline reprocessing unchanged data can multiply consumption several times over for the same business output.
Workload mix. Spark notebooks, warehouse queries and Power BI rendering all draw from the same pool. An estate doing all three at once needs more headroom than one doing only reporting.
How Smoothing and Throttling Actually Work
This is the part that makes Fabric capacity behave differently from a server, and misunderstanding it produces both over-buying and nasty surprises.
Fabric does not fail the moment you exceed your capacity. It smooths consumption over time, spreading the cost of operations across a window so that short bursts are absorbed rather than rejected. Background operations such as scheduled refreshes are smoothed over a long window; interactive operations over a much shorter one.
When sustained demand exceeds what the capacity can smooth, you hit throttling: operations are delayed, and in the worst case rejected, until consumption falls back into range.
Two consequences worth internalising:
- Going over does not cost you money. Unlike consumption-priced platforms, exceeding a Fabric capacity costs you performance, not budget. The financial risk is over-buying, not overspending.
- Short spikes are fine. You do not need to size for your absolute peak second. You need to size so that sustained demand fits.
A Method That Works
1. Start one tier below instinct, on pay-as-you-go. Undersizing is visible within days and trivially fixed by scaling up. Oversizing is invisible - you simply pay for headroom, potentially for a reserved year.
2. Run genuinely representative workloads for two to four weeks. Not a demo. Real refresh schedules, real report usage, month-end included if that is your peak. A fortnight that excludes your busiest period tells you nothing useful.
3. Read the Capacity Metrics app. It shows consumption over time, which items are responsible, and whether throttling occurred. This is the single most useful artefact in the whole exercise and it is free.
4. Fix the obvious inefficiency before buying more. If one badly-written dataflow accounts for a third of consumption, the answer is not a bigger SKU. This step routinely saves a tier, which over a reserved year is real money.
5. Then reserve. Once the pattern is stable, a one-year reservation saves roughly 41% against pay-as-you-go. See the full F SKU price list.
The F64 Exception
One threshold overrides the sizing logic entirely. At F64 and above, report viewers no longer need individual Power BI Pro licences.
For an organisation with a large report audience, the arithmetic can invert the whole decision: a few hundred viewers on Pro licences can cost more per year than the jump from F32 to F64. Plenty of organisations run F64 for the licensing rather than the compute, and are right to.
Work this out before sizing on performance alone. Our licensing guide covers who needs what.
Development, Test and Pausing
Pay-as-you-go capacities can be paused, and a development capacity that runs only during working hours costs roughly a quarter of an always-on one. The common arrangement is a reserved production capacity plus a small pay-as-you-go capacity for development that pauses overnight and at weekends.
Reserved capacities cannot be paused, which is exactly why they suit steady production and not experimentation.
Common Sizing Mistakes
- Sizing on data volume. Covered above, and still the most frequent error.
- Reserving on day one. You do not yet know your consumption pattern. Reserve in month two or three, not week one.
- Sizing for the average. Capacity is sized by sustained peaks. Month-end usually sets the number.
- Ignoring the development estate. Building on the production capacity works until a bad notebook throttles live reporting.
- Treating the first number as permanent. Consumption changes as adoption grows. Re-read the metrics quarterly; that is what the app is for.
Where Solv Systems Comes In
Capacity sizing is part of every Fabric engagement we deliver, and we run it as a standalone review for organisations who have already built the platform and suspect they are on the wrong tier.
The work is unglamorous: instrument the estate, run representative load, read the metrics honestly, fix the inefficiency that is inflating consumption, and only then recommend a SKU and a reservation. It frequently ends with a recommendation to buy less than the client expected, which is the outcome that makes the exercise worth running.