Most Fabric capacity planning conversations start in the wrong place. Someone reports that reports are slow, someone else notices throttling in the metrics, and within a week there is a proposal to move from F64 to F128.
That proposal might be right. But scaling in Fabric is not a dial, it is a doubling, and Microsoft’s own guidance is blunt about the order of operations: optimise first, expand only when necessary. This piece covers what to read before you sign for the next SKU, and the three numbers that tell you whether you have a capacity problem or a workload problem.
Scaling up always doubles
This is the constraint that shapes every other decision, and it catches finance teams more than architects.
Fabric F SKUs scale by doubling. There is no F96 between F64 and F128. So the question is never “how much more capacity do we need”, it is “do we need twice what we have”. For an estate running at 85% of an F64, doubling means paying for an F128 that will sit at roughly 42%, and that gap is the entire commercial argument for optimising first.
It also means the interesting option is often not scaling at all. F SKUs can be resized and paused. Scheduled resizing, scaling up at quarter end and back down afterwards, can be automated through the Fabric CLI, Azure Automation or the REST APIs. For predictable surges that is usually cheaper than carrying the larger SKU permanently.
There is a rule of thumb worth committing to memory for the reverse direction. If you are considering scaling down from F128 to F64, the smoothed usage on the F128 needs to sit below 40%, because it will become 80% at half the size. Teams that check current usage rather than doubled usage scale down and get throttled within days.
Utilisation above 100% does not mean you are throttled
This is the single most common misreading of the metrics app, and it sends teams to procurement who did not need to go.
A spike over the line on the utilisation chart indicates an overage, not throttling. Fabric is built to absorb overages. Microsoft states plainly that utilisation exceeding 100% doesn’t automatically mean throttling, and directs you to the separate Throttling chart to evaluate whether anything actually degraded.
Two mechanisms do that absorbing, and they are worth understanding before you read any chart.
Bursting lets an operation temporarily use more compute than the SKU provides, so a job finishes fast instead of being rationed. It is also what allows a smaller capacity to run an operation that would otherwise demand a larger one.
Smoothing then averages that consumption forward so the burst does not immediately trigger throttling. The window depends on the operation type, and this is the detail most summaries get wrong:
- Interactive operations smooth over a minimum of five minutes, up to 64 minutes, depending on consumption.
- Background operations smooth over 24 hours, because they typically run long and consume heavily.
Fabric divides time into 30-second timepoints, 2,880 of them across a day, and distributes consumption across them.
The throttling stages, which tell you how bad it actually is
Throttling is progressive, not binary, and the stage you are in is the most useful number in this whole exercise. Before any of it, the capacity grants overage protection: ten minutes of future capacity can be consumed with no throttling at all.
| Future capacity consumed | Stage | What users experience |
| Up to 10 minutes | Overage protection | Nothing. This is normal operation |
| 10 to 60 minutes | Interactive delay | Interactive jobs delayed 20 seconds at submission |
| 60 minutes to 24 hours | Interactive rejection | Interactive jobs rejected. Background jobs still run |
| Over 24 hours | Background rejection | All requests rejected |
Someone reporting that reports feel sluggish is describing stage one, a 20-second delay. Someone reporting that reports have stopped is describing stage two. Those are very different problems and only the second is urgent.
Two reassurances worth knowing. In-flight operations are never throttled: anything already submitted runs to completion, even during a surge. And capacities are self-healing, so waiting is a legitimate remediation. The metrics app estimates minutes to burndown, which tells you how long waiting would take.
Real-Time Intelligence is an exception worth flagging if you run it: it skips the 20-second delay stage entirely and only begins throttling at the rejection phase, because a real-time system delayed by 20 seconds is not real-time.
The readings that decide whether to scale
With that context, three readings answer the scaling question between them.
| Reading | What it means | What to do |
| Peak consistently above 80% | The capacity is genuinely tight at peak | Split workloads onto a second capacity, or scale up |
| Peak consistently below 30% | The capacity is oversized | Consolidate workloads onto it, or scale down |
| Sustained throttling, not overages | Operations are being delayed or rejected | Find the top consumer before buying anything |
The metrics app shows top consumers by workspace and by item, and the drill-through on a timepoint reveals which operations caused an overage. In practice a single semantic model or an unbounded Spark job is often responsible for a disproportionate share.
Microsoft’s guidance suggests a trend-based test rather than a snapshot: if peak usage has moved 60%, then 75%, then 90% across successive reviews, scale before you reach the ceiling rather than after. A single bad afternoon is not a trend.
What is actually consuming it
In our experience it is rarely the workloads people expect. Three causes account for most of it.
A new workspace nobody accounted for. Capacity is a shared resource, so adding a workspace adds load that was never in anyone’s monitoring. It arrives as a surprise rather than as a known risk, which is the whole problem.
Gradual degradation. Semantic models and ETL processes slow down and consume more over time as data volumes grow and other factors accumulate. These changes are slow, which is precisely why they go unnoticed. They need periodic monitoring and review so optimisation can be planned proactively rather than triggered by an incident.
Dead artefacts. Work that is no longer needed but was never retired sits in the capacity consuming resources indefinitely. Knowing what is actually in a workspace is the same discipline that decides whether Git integration covers it, and estates tend to be weak at both for the same reason. Retiring artefacts properly when they stop being needed is unglamorous housekeeping and it is one of the highest-yield things a platform team can do.
What this means when you are actually throttled
Two consequences follow from 24-hour smoothing of background work, and both surprise people.
A capacity can be throttled by work that finished yesterday. And testing a change by running it once and watching the meter will mislead you, because the effect arrives gradually and persists for a day.
When throttling does bite, there are three ways out beyond simply waiting for burndown.
Temporarily increase the SKU. A larger capacity has more idle headroom in each timepoint, so it burns down the accumulated carryforward faster.
Pause and resume. Pausing bills the accumulated future capacity as a one-time event. When the capacity resumes it has zero future usage, so it accepts new operations immediately. That makes pause a remediation tool as much as a cost control.
Enable capacity overage billing. It works, and it is charged at three times the normal capacity rate, so it is an emergency valve rather than an operating model.
Capacity planning in Fabric is a rolling-window exercise, not a peak-instant one, and that is by design.
Surge protection, and what it will cost you
Surge protection is the control most estates should enable and most do not, because its trade-off is not obvious until you read the detail.
It prioritises interactive work by limiting background compute when 24-hour usage is high. If user-facing reports share a capacity with refreshes and AI jobs, that is exactly the behaviour you want at 9am on a Monday.
Three caveats matter, and they are the reason it is not simply on by default:
- When active, it rejects background jobs. Those need delaying or rerunning.
- Many operations you would call interactive count as background, including SQL queries, and can be rejected.
- It is not a substitute for correct sizing. Critical workloads still need dedicated capacity.
So surge protection protects the report a director is opening, at the cost of a pipeline that now needs a rerun. That is usually the right trade, but it should be a decision rather than a discovery.
Chargeback: useful, but not the answer people expect
The Fabric chargeback app attributes capacity usage to departments. It is worth being honest about what it can and cannot do for you.
In most organisations it is a nice to have rather than a control, because it is not genuinely usable until the company’s operating model defines chargeability in the first place. If nobody can actually be billed, chargeback does not change any budget.
Where it does earn its place is as a guiding line for responsible use. Shared capacity is a commons, and a commons with no visible meter gets treated accordingly. Once a business unit can see the share it consumed and roughly what that means in monthly cost, behaviour tends to change without anyone enforcing anything. Heavy refreshes move off peak. Redundant semantic models get retired.
It also helps the funding conversation when a team asks for more capacity, because the data shows who is driving the consumption. But treat that as a benefit rather than the reason to implement it.
Pair it with fair use guidelines, written down and communicated: refresh frequency limits, data volume caps, and what happens if a team consistently overloads shared capacity. Microsoft’s guidance suggests naming the consequence explicitly, up to moving a persistent offender to a quarantine capacity.
Our position: size for 75% average, and start lower than you think
Size the F SKU so that average usage stays below 75%. That leaves genuine headroom for surges rather than relying on the platform to absorb everything.
Note how that sits alongside Microsoft’s guidance. The 80% figure above is an action threshold measured at peak: cross it consistently and you should do something. Ours is a planning target measured on average, and it is deliberately more conservative, because the point of headroom is that you have it before you need it.
Then start with a lower SKU and analyse the usage pattern before you double. Underutilised capacity is a liability to the organisation just as an overloaded one is, and it is the easier mistake to make because nobody complains about it.
The principle underneath both:
Bursting and smoothing are designed to absorb surges. A surge should be treated as a surge, not as a design. If your steady state depends on bursting, you have not sized the capacity, you have borrowed against it.
Reserved instances against pay as you go
The commercial structure has one threshold worth knowing.
Reserved instances give the better rate for baseline capacity. Pay as you go gives flexibility for peaks. The dividing line Microsoft suggests is four days a week: if the extra capacity is needed more often than that, a reserved instance is better value than paying the on-demand premium.
Below that threshold the pattern is to hold the baseline as reserved and add pay-as-you-go capacity for the predictable surge, for example running an F64 reserved with an additional F64 added on Mondays rather than committing to F128 for the whole week.
One related detail that surprises people: pausing a capacity settles any overuse as a one-time pay-as-you-go billing event. That resets usage and prevents throttling, which makes pause a remediation tool as well as a cost control.
If you are setting quotas in the Azure portal, allow a 25% to 50% buffer above your assessed need for peaks and throttling headroom.
What good looks like operationally
Fabric capacity planning fails as a project and works as a habit. The estates that stay healthy tend to do the same handful of things.
- Review on a cadence, monthly or quarterly, and make scaling a scheduled decision rather than an incident response.
- Alert on thresholds so an overloaded capacity notifies an admin rather than a user.
- Optimise before scaling, every time: slow measures, unnecessarily frequent refreshes, pipelines stacked on the same hour, semantic models that should use incremental refresh.
- Forecast from evidence. If 50 new users pushed peak consumption up 20%, another 100 users implies roughly 40% more, and that arithmetic justifies the SKU well before anyone is complaining.
- Keep an owner per capacity. Enterprise capacities need a named admin the way production systems do.
What this looks like on a real migration
Capacities are usually either undersized or oversized, and the reasons are mirror images of each other: conservatism on one side, over-protection on the other. What organisations actually need is a mix that fits their loads and their costs.
The common assumption is that an F64 will run everything without additional charges. It will, if it is used wisely. Well-planned loads and deliberate downtimes are what let you get the most out of whichever SKU you choose.
A recent sizing exercise makes the point. A client was migrating off Synapse plus Power BI P1, and the P1 was autoscaling to P2 almost every other day. We recommended F64, with a clear caveat attached: tune the existing load first, then eliminate Synapse in phases.
The client chose F128 for the migration phase instead, to avoid any unknown costs.
The result is worth sitting with. Rather than landing on a balanced cost somewhere between F64 and F128, they committed to the full cost of an F128 on a reserved instance. The caution was understandable and it was not free. In our engagements that gap, between the recommendation and the decision actually taken, is where a great deal of Fabric spend goes.
Where to start
Open the capacity metrics app before you open a purchase requisition. Read peak against 80%, read the floor against 30%, and read throttling against zero. If throttling is not zero, find the top consumer before you decide the capacity is too small, because it usually is not.
Then turn on chargeback, even if you never bill anyone. Visibility does more for consumption than governance does.
Veratas runs Microsoft Fabric platform assessments that include capacity sizing, and the data consulting work that decides how an estate should be structured before capacity becomes the question.
If you are being asked to approve a capacity increase and nobody can name the top consumer, talk to our team. That is a short piece of work with a large number attached to it.
Frequently asked questions
When should I scale up a Fabric capacity? When peak usage sits consistently above roughly 80% and you have already optimised the top consumers. Because F SKUs double, scaling is a large commercial step and Microsoft’s own guidance is to optimise first and expand only when necessary.
Why does my capacity show usage from jobs that already finished? Background operations are smoothed over 24 hours, so a large job spreads its consumption across the following day rather than spiking when it runs. A capacity can be throttled by work that completed yesterday.
Can I scale down from F128 to F64 safely? Only if smoothed usage on the F128 is below 40%, because it will read as 80% at half the size. Checking current usage rather than doubled usage is the common way teams get throttled after scaling down.
What does surge protection actually do? It protects interactive workloads by limiting background compute when 24-hour usage is high. It rejects background jobs, and many operations you would consider interactive, including SQL queries, count as background and can be rejected.
Is the Fabric chargeback app worth it if we do not cross-charge? Usually yes. Most organisations use it for showback rather than billing, and visibility alone tends to change consumption behaviour and makes funding discussions concrete.
Reserved instance or pay as you go? Hold baseline capacity on a reserved instance and add pay as you go for peaks. If the additional capacity is needed more than about four days a week, a reserved instance is the better value.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.