# Microsoft Fabric Capacity: Sizing, Smoothing, and Throttling

*Published 2024-10-15 · Dmitry Shirokov · shirokoff.ca/blog/fabric-capacity-sizing-throttling*

The report was slow — not broken, slow, in the way that makes users refresh and make it worse. Nothing about it had changed. What had changed was a data scientist three floors away starting notebook experiments on the same capacity, with no idea "capacity" was something you share. **Fabric does not bill you for queries. It bills you for a capacity — a fixed pool you rent by the hour — and meters work against it in capacity units, smoothed over time.** Every cost instinct from a per-query warehouse is wrong here.

## The mechanism

You buy an **F SKU** (F2, F4, F8…, roughly CUs per second). Everything — Power BI queries, Spark notebooks, pipeline copies, warehouse queries, eventstreams — draws from the pool.

| Concept | What it does | Why it matters |
|---|---|---|
| **Bursting** | One operation may exceed the SKU rate to finish faster | Your notebook isn't capped — it borrows against the future |
| **Smoothing** | Cost is spread over a *following* window, not charged instantly | Why a spike doesn't kill you, and why yesterday's spike throttles you today |
| **Throttling** | Overage → delay, then rejection | Reports get slow *before* anything gets rejected |

Smoothing is the piece that makes Fabric behave unlike anything else: **the throttling you feel at 9am can be debt from a job that finished at 2am**, so "what's running now?" tells you nothing. Interactive and background work smooth over different windows, which is what lets a nightly batch coexist with business-hours reporting — unless the batch runs so hot its debt is still being repaid at login time.

## Sizing without guessing

Don't size for peak; bursting and smoothing exist to absorb peaks. Size for **sustained average with enough headroom that peaks are repaid before the next one**. Method: (1) **measure a representative fortnight** on pay-as-you-go, including a month-end — headcount-based guesses are wrong because refresh behaviour varies tenfold; (2) **read the timeline, not the average** — brief ceiling touches are fine, hours at the ceiling means someone is already waiting; (3) separate **peak size from peak frequency** — a monthly monster is a scheduling problem, a daily 4pm collision is a sizing or separation problem; (4) then split **reserved baseline vs pausable pay-as-you-go**, which usually argues for several capacities rather than one large one.

**Pause** is the biggest lever for non-production — a dev capacity running 24/7 for a business-hours team is ~75% waste. Automate it. And know that **pausing settles the smoothed debt**: work you'd have spread forward bills at pause time. Not a loophole, an accounting boundary.

## Capacity design = blast radius

Everything on a capacity competes for the same CUs, so "who can slow down my reports?" answers itself. Separate **production reporting from experimentation**; group **by SLA, not by org chart** (team-shaped assignment produces one critical report sharing with forty experiments); keep dev/test **pausable and paused**; and watch the cross-capacity gotcha — a report reading a semantic model in another workspace consumes CU where the *model* lives.

FinOps framing applies with one wrinkle: because the bill is flat, **optimization doesn't reduce the invoice** until you resize or pause — it buys headroom. Worth saying explicitly to a sponsor who expects per-query savings.

## Three ways teams get hurt

**Sizing on peak and never revisiting** — an F64 bought "to be safe" is a standing bill for headroom you may not need once two jobs move off business hours. **Treating throttling as a platform fault** — the slow-report ticket goes to the semantic model instead of the capacity timeline; if reports are slow and nothing about them changed, look at capacity *before* DAX. **One workspace holding everything** — the default path, cheap to fix early, expensive after forty workspaces exist. And on reserved SKUs: reservations don't autoscale, so keep headroom or a pay-as-you-go capacity alongside for overflow.

## Monitoring

Install the **Capacity Metrics app** when you stand up the capacity, not during the incident. Watch the **utilization timeline** (how often and how long smoothed usage hits the ceiling), **throttling events** split into delay vs rejection (any interactive delay means a user waited), and **top consuming items** over a window — usually one bad notebook or over-frequent refresh is a third of consumption and a five-minute fix. Alert on sustained plateaus, not spikes: spikes are what bursting is for.

*Related: [Microsoft Fabric internals](https://shirokoff.ca/blog/ms-fabric-internals) · [FinOps for data platforms](https://shirokoff.ca/blog/finops-data-platforms) · [Synapse vs Databricks](https://shirokoff.ca/blog/azure-synapse-databricks) · [Power BI semantic models](https://shirokoff.ca/blog/power-bi-semantic-models)*