What a capacity actually is#
Every notebook run, report refresh, or pipeline in Fabric draws compute from somewhere. That somewhere is a capacity: a dedicated pool of resources that performs work in Fabric, measured in capacity units (CUs), the single unit Fabric uses to meter compute. Every workload draws CUs from the capacity backing it, and consumption is classified as interactive (a person waiting on a result) or background (a scheduled job) [S1].
A capacity is a distinct resource pool living inside your organization's Microsoft Entra tenant. Its SKU size — F2, F64, and so on — sets how much compute it provides, and a tenant can hold as many capacities as it needs, often split by geography or business unit [S2]. The Fabric trial grants an F64-equivalent capacity (64 CUs) for 60 days, behaving like F64 for Power BI viewing rights too — a realistic sandbox before purchase [S2].
Capacity size also gates who can see content, not just who runs work: only Power BI Premium or Fabric capacities of F64+ let free-license users view shared content, and a capacity is required for Copilot at all [S3].
What happens when a capacity runs out#
When a capacity saturates and rejects requests, users see the HTTP status CapacityLimitExceeded [S4]. That rejection is scoped to the capacity itself — Fabric throttles at the capacity level, not the tenant level, so a saturated capacity only affects its own assigned workspaces, while every other capacity keeps running normally [S4].
Sharing a capacity across teams#
A common pattern is hybrid allocation: put lighter workloads from several departments on one shared capacity, and give a heavier or more sensitive department its own dedicated capacity. Organizations often start consolidated for cost efficiency and split capacities out later as usage grows [S5].
A worked example#
A company starts with one shared F64 capacity for finance and marketing reporting. As data engineering ramps up nightly Spark jobs on it, finance's morning refreshes start hitting CapacityLimitExceeded during the overlap [S4]. Instead of buying one bigger capacity for everyone, the team splits data engineering onto its own dedicated capacity, following the hybrid pattern of separating a heavier workload out once contention appears [S5]. Finance and marketing stay on the shared capacity, unaffected, because throttling doesn't cross capacity boundaries [S4].
What goes wrong#
- Assuming a busy capacity throttles the whole tenant. Only its own assigned workspaces are affected [S4].
- Under-sizing to save cost, then losing free-license viewers. Below F64, free-license users can't view shared content, and Copilot needs a capacity at all [S3].
- Treating every workload as needing its own capacity from day one. The common pattern starts consolidated and splits later, once real contention shows up [S5].