Microsoft Fabric has quickly become a go-to platform for unified analytics, but running workloads at scale introduces a fundamental challenge: compute demand is unpredictable. One moment your pipeline is idle; the next, a dozen reports fire simultaneously, and a Spark job kicks off in the background. Without a smart way to handle these spikes, you’d either over-provision capacity (wasting money) or watch jobs fail under load (wasting trust).
That’s exactly the problem that Smoothing and Bursting are designed to solve. Together, they form Fabric’s capacity management safety net — absorbing peaks, deferring overages, and preventing hard failures, so your workloads keep running even when demand temporarily exceeds what your SKU nominally provides.
Understanding Fabric Capacity Units (CUs)
Before diving into the mechanics, it helps to understand the currency. Fabric capacity is measured in Capacity Units (CUs). Every SKU — from F2 to F2048 — comes with a fixed pool of CUs per second. When a workload runs, it consumes CUs. When it finishes, those CUs are freed.
The challenge is that consumption of CU isn’t flat. An interactive Power BI report might consume a burst of CUs for two seconds and then drop to zero. A notebook might hammer the capacity for 20 minutes. Managing this variety of shapes and durations is where smoothing and bursting come in.
What is Bursting?
Bursting allows a workload to temporarily consume more CUs than your SKU’s baseline allocation. Think of it as a credit line on top of your base capacity.
When a job needs CUs and your capacity has headroom — meaning recent consumption has been low — Fabric allows it to draw beyond the nominal limit. This prevents failures that would otherwise occur simply because a workload arrived at a moment of peak demand.
Bursting is particularly valuable for interactive workloads like Power BI report refreshes and Direct Lake queries. These are latency-sensitive: a user clicks on a slicer and expects a response in seconds. Without bursting, a momentary spike could throttle the response or fail the request entirely. With bursting, Fabric dips into reserved headroom to serve the request immediately, then recovers that usage over time.
The key constraint is that bursting isn’t free. Every extra CU consumed during a burst must eventually be “paid back.” This is where smoothing takes over.
What is Smoothing?
Smoothing is the process that spreads CU use over a longer time instead of just giving it all to the moment it happens. For example, if a workload causes a sudden spike, like a notebook that uses 200 CUs in one second, Fabric doesn’t punish the full 200 CUs at that moment. Instead, it distributes, or “smooths,” that consumption across a rolling window (typically up to 10 minutes for background jobs). The spike is acknowledged, but its effect on the capacity meter is smoothed out.
This has a very bad side effect: it stops throttling cascades. Without smoothing, a single heavy job could instantly push capacity utilization to 100%, which would cause throttling that delays every other workload that is waiting behind it. With smoothing, the same job footprint is spread over time, giving other workloads room to breathe.
Smoothing works differently depending on the type of workload:
Interactive operations (like Power BI visuals and on-demand queries) are smoothed over shorter windows because users are actively waiting.
Scheduled refreshes, pipelines, and Spark jobs are examples of background operations that can handle delays better over longer periods of time. This tiered approach keeps user-facing experiences fast while batching jobs to handle the effects of heavy use without slowing down.
Bursting and smoothing are two sides of the same coin. Bursting handles the intake, letting workloads consume more than the baseline in real time, while smoothing handles the accounting, spreading that overconsumption over time, so the capacity meter doesn’t spike into throttle territory.
For example, let’s say you’re F64 capacity has been lightly used all morning. At 10 AM, 15 users open a heavy Power BI report at the same time. Bursting kicks in, using the “quiet time” headroom that has built up to serve all 15 requests right away. Smoothing then spreads the cost of that burst over the next few minutes, so the capacity monitor doesn’t immediately show a 100% utilization alarm.
The end result is no failure, no throttling, and no user staring at a spinning wheel in frustration.
Why This Matters for Capacity Planning
Knowing how to smooth and burst changes the way you think about right-sizing your Fabric capacity. You don’t need to provision your absolute peak; you need to provision your sustained average, knowing that spikes will be absorbed by the burst mechanism and smoothed into the utilization window.
At this point, it is very important to use the Fabric Capacity Metrics app. It shows you utilization trends, throttling events, and how your workloads are being smoothed over time, giving you the data to tune SKU size with confidence rather than guesswork.
Smoothing and bursting won’t solve infinite overload — if your capacity is consistently maxed out, no amount of smoothing will prevent throttling. But for the realistic peaks and valleys of enterprise analytics workloads, they are the quiet, powerful mechanisms that keep Fabric humming when it matters most.
