Capacity Unit (Microsoft Fabric)

A capacity unit (CU) is the measure of compute a Microsoft Fabric capacity provides. A capacity is, in Microsoft’s words, a distinct resource pool, and its size is expressed in CUs: the F SKU number equals the number of capacity units, from F2 with 2 CUs up to F8192 with 8,192. By default, every workspace assigned to that capacity draws its compute — Spark jobs, warehouse queries, Power BI refreshes — from the same pool; the exception is on-demand billing for Spark, which, when enabled, moves Spark jobs to separately billed serverless resources.

How capacity is bought

• F SKUs are purchased through Azure, billed per second with a one-minute minimum, with no commitment required; reservations reduce the price for steady use.
• A workspace can be reassigned to another capacity in the tenant. Running jobs are canceled, and a move across regions works only for movable item types, which excludes lakehouses and warehouses.
• The older P SKUs are being retired; F64 is the size Microsoft lists as equivalent to P1.

Why the size matters beyond compute

The CU count also changes licensing. According to Microsoft’s licensing documentation, on capacities smaller than F64 every user who views Power BI content needs a Pro or Premium Per User license; from F64 upward, users with a free license and a viewer role can view content. For an organization with many report readers, that boundary can outweigh the compute difference between sizes. Premium Per User licenses, the same documentation notes, do not provide Fabric capacity.

The CU count sets other allowances too. For example, mirroring includes one terabyte of free mirroring storage for each capacity unit purchased, so an F64 includes 64 TB for mirrored data.

Shared budget, shared failure

Because the workloads billed against a capacity draw from the same CUs, the capacity is both a shared budget and a shared point of contention. Fabric absorbs short spikes through bursting and smoothing, but when sustained demand exceeds the CUs available, throttling applies to the whole capacity — a heavy nightly job on one workspace can delay a dashboard on another. Another capacity keeps its own throttling state, but work that crosses capacities — a report querying a semantic model hosted on another capacity, for instance — is exposed to both.

That makes capacity assignment a design decision rather than an administrative one. Workloads that must not compete for capacity units belong on separate capacities, or, for Spark, on on-demand billing; either removes contention for CUs, not shared data or external dependencies. Sizing a capacity is about the combined peak and recovery pattern of everything billed against it, not about any single workload. How this fits into Fabric’s architecture is worked through in Microsoft Fabric Architecture: OneLake, Capacity, and the Move from Synapse.

References:

• Microsoft Learn, Understand Microsoft Fabric licenses and capacity
• Microsoft Learn, Understand capacity throttling and smoothing
• Microsoft Learn, Mirroring
• Microsoft Learn, On-demand billing for Apache Spark in Microsoft Fabric
• Microsoft Learn, Capacity reassignment restrictions and common issues