In Microsoft Fabric, capacity defines how much compute your workspace can consume. Each SKU (like F2/F8/F64 & above.) provides a set of Capacity Units (CUs) that determine the sustained workload limit. However, workloads in Fabric are dynamic, notebooks, pipelines, PBI refreshes, and real-time jobs rarely consume a constant load. This is where bursting comes in. It allows your workloads to temporarily exceed the baseline compute limit for short durations without performance degradation.
What is Bursting?
Bursting is Fabric’s mechanism to handle short term workload spikes. Each capacity can go up to 2x of its provisioned CU limit (in most SKUs) for a limited period.
For example:
- An F64 capacity can burst up to 128 CUs briefly.
- The Fabric engine tracks usage continuously in a rolling time window (usually 24 hours) and applies smoothing and throttling based on how consistently the capacity is overloaded.
Essentially, bursting is a grace mechanism to ensure that workloads experiencing momentary peaks like a dataset refresh or Spark job start do not instantly get throttled.
How Bursting Works Internally
When you trigger a job (say a spark notebook), behind the scene the Fabric engine checks:
- Current CU utilization (For example: 40 out of 64).
- Instantaneous demand: Say the new job needs 30 CUs
- Cumulative average usage window to determine if bursting is allowed.
If there is headroom within burst limits, fabric temporarily allocates additional CUs beyond your base allocation. However, this allocation is not guaranteed and depends on overall tenant level resource availability (since fabric capacities share backend clusters).
If bursting continues for long periods, Fabric’s smoothing algorithm gradually limits the available burst to bring the capacity back to equilibrium leading us to the next mechanism, smoothing.
Visualizing Bursting in Real Time
You can observe bursting in your trial fabric capacity using the Capacity Metrics App:
- Go to the Fabric Admin Portal -> Capacity Settings -> Metrics app -> Open in PBI.
- In the Utilization tab, observe the “CU consumption” metric over time.
- Trigger a heavy workload (run a large Spark Notebook or refresh a large PBI dataset).
- Watch for spikes above your capacity’s baseline CU limit that is bursting in action.
If you notice the capacity exceeding its baseline but still performing smoothly, you are within the burst window.
Behind the Scenes, how does the Bursting works?
Fabric implements bursting through its capacity scheduler, which runs in Azure’s underlying compute cluster. Each workspace operation (notebook, dataflow, refresh) is assigned CU cost weights, and the scheduler continuously evaluates:
- Sustained vs. short-term load
- Priority of workloads (interactive vs. background)
- Burst headroom (how far above baseline you can go)
- Recent throttling incidents
This distributed capacity controller ensures fairness across tenants while still allowing elasticity.
Practical Demo to See Bursting
- In your trial capacity select F64: [Though bursting works on all SKUs, F64 is recommended to see visible impact. These SKUs also tend to have more consistent backend cluster resources, so bursting succeeds more often]
- In Workspace A, run two Spark notebooks simultaneously loading large CSVs or performing joins.
- In Workspace B, refresh a PBI dataset concurrently.
- Open the Metrics app and check if “CU usage” crosses the baseline CU line.
- Note that jobs still run smoothly that is bursting compensating for the spike.
Conclusion
Bursting in Fabric is a performance cushion. It keeps workloads responsive during brief demand peaks without forcing capacity scaling. However, please note that it is not a substitute for right sizing as prolonged bursting will trigger Smoothing and eventually Throttling. Understanding how bursting interacts with smoothing and throttling (both Smoothing and Throttling are for the upcoming deepdives) helps architects plan workloads efficiently and avoid unexpected slowdowns.