Series: Capacity Planning & Cost Management
If there’s one concept that trips up nearly everyone moving into Fabric, it’s capacity units — because a CU isn’t what most people assume it is.
It’s compute, not seats.
A Capacity Unit has nothing to do with user counts or license tiers. It measures compute power, consumed in CU seconds as work actually runs. A report rendering, a pipeline moving data, a notebook chewing through a dataframe — all of it draws from the same shared pool of CU seconds on your capacity. Think of it less like a parking pass and more like a utility meter — it just keeps ticking based on what’s actually being computed, no matter who’s asking for it.
The F-SKU ladder doubles at every step.
Fabric capacities run from F2 up to F2048, with F4096 and F8192 available for the largest tenants. Each step roughly doubles both the CU count and the price: F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048. If you’re coming from Power BI Premium, F64 is your anchor point — it’s the rough equivalent of the old P1 capacity. That doubling pattern makes napkin math easy once you know your starting point — double the SKU, roughly double both the price and the throughput you get.
Every workload spends differently.
Spark jobs, SQL and warehouse queries, Power BI report interactions, and Data Factory pipelines all draw from the same CU pool, but each is metered under the hood in its own way. Spark can even run in a pay-as-you-go “autoscale billing” mode that skips the usual smoothing rules entirely. That means two capacities running the exact same CU number can feel completely different day to day, depending on whether that load is coming from Spark, SQL, or report interactions.
Bursting lets you borrow ahead.
Fabric allows operations to temporarily exceed what your SKU technically provides, so a smaller capacity can absorb an occasional heavy job without forcing you to buy more headroom than you need day to day. It’s the built-in flexibility that keeps you from having to size your capacity for the worst day of the year instead of a typical one.
Smoothing spreads out the spike.
Interactive work — opening a report, running a query — gets smoothed over roughly 5 to 64 minutes. Background work like a pipeline or warehouse load gets smoothed across a full 24 hours. That’s why one big overnight job rarely throttles a capacity, but repeated heavy interactive usage will. It’s the reason two workloads that look identical on paper can behave completely differently on your capacity — one folds into a long window unnoticed, the other lands all at once.
Reserved versus pay-as-you-go is a real decision, not a formality.
Reserved capacity — a 1-year or 3-year commitment — saves real money for steady, predictable production workloads. Pay-as-you-go hourly billing fits dev/test environments or usage patterns you haven’t nailed down yet. Treat it like a phone plan: lock in a rate once you know your usage pattern, but stay flexible until you do.
Get comfortable with CUs now, because every sizing and pricing conversation you’ll have later in your Fabric journey traces straight back to this one concept.
To learn more: Understand Microsoft Fabric licenses and capacity · Understand capacity throttling and smoothing · Scale your capacity in Azure · Save costs with Microsoft Fabric Capacity reservations (all Microsoft Learn)
This post is part of the Fabric & Power BI Essentials series — see the full series intro and article list there.
← Previous: Planning a Fabric Solution Fit for Your Organization | Next →: Choosing Your First Capacity: F2 vs. F4 vs. F64 and Why It Matters
