Understanding Fabric Capacities: Fundamentals and Administration

Part 1 of the Fabric Capacities demo series.

If you are working in Microsoft Fabric, capacities are something you will run into quickly. Whether you are an admin trying to figure out why jobs are slowing down, a developer who just got an error about throttling, or an architect trying to size a new environment, you need a solid mental model of how capacities actually work.

This post covers the fundamentals: what a capacity is, the different types and SKU tiers available, how to buy and right-size one, and the key administrative settings you should know about.

What is a Fabric Capacity?

At its core, a Fabric capacity is a pre-reserved pool of compute that powers every workload in Microsoft Fabric. Data Factory pipelines, Spark notebooks, warehouses, eventstreams, Power BI reports - all of them draw from the same shared compute pool. There is no separate compute budget per workload type. It is all unified.

Compute is measured in Capacity Units (CUs). The more CUs you provision, the more concurrent load your capacity can support. When you scale up to a larger SKU, you are doubling the CU count.

The key thing to understand about the billing model: you pay for reserved compute, not just what gets consumed. The capacity is available around the clock whether workloads are running or not. Unused CUs in a given period do not carry forward.

Fabric adds two mechanisms on top of this base model that make it more flexible than a hard compute ceiling:

• Bursting - jobs can temporarily exceed the base CU allocation to finish faster without waiting in a queue. Fabric will allow this rather than throttle you immediately.
• Smoothing - the CU cost of a job is spread across future timepoints rather than being charged all at once. This means short spikes do not immediately push your capacity into throttling territory. Background operations like Spark jobs are smoothed over 24 hours. Interactive operations like Power BI queries are smoothed over a minimum of 5 minutes.

We will go much deeper on bursting, smoothing, and throttling in Part 3 of this series. For now, knowing that these mechanisms exist is enough context to understand why the capacity model feels more forgiving than a hard quota.

Capacity Types

There are four capacity types in Fabric:

F SKU Tiers

F SKUs come in tiers from F2 up to F2048, with the CU count doubling at each level:

Buying and Sizing Your Capacity

Two Purchasing Models

Pay-As-You-Go : billed per minute with a one-minute minimum. You pay the full hourly rate, but you can pause the capacity when it is not needed and only pay for what you use. This is the right choice for dev/test environments, variable workloads, or when you are still figuring out the right SKU size.

1-Year Reservation: a significant discount versus the pay as you go rate. The reservation applies to the reserved SKU size. If you scale above your reservation, the extra CUs are billed as pay as you go. Reservations make sense once you have a stable, predictable production workload and you know roughly what SKU you need.

Three Things to Know Before You Buy

Region selection: capacities are provisioned to a specific Azure region and pricing varies by region. This matters architecturally because a workspace that contains Fabric items cannot be moved to a capacity in a different region. Plan your regions carefully upfront.

Fabric quotas: each Azure region has a cap on the total CUs that can be provisioned. If you hit the quota, provisioning will fail. You can request a quota increase through the Azure portal, but it is worth checking availability in your target region before designing your architecture around a specific SKU.

Right-sizing: the question everyone asks is "what SKU do I need?" The honest answer is that it depends heavily on your workloads. Microsoft has a SKU Estimator at aka.ms/fabricskuestimator that gives you a ballpark recommendation based on your data volume, batch cycles, and planned workloads. Use it as a starting point, not a final answer.

The Two-Step Sizing Process

My recommended approach for right-sizing before committing to a paid SKU:

Step 1 - Ballpark with the SKU Estimator: plug in your workload profile (data volume, daily batch cycles, table counts, which Fabric features you plan to use) and get an estimated SKU. Export the results to Excel if you want to model out different scenarios.

Step 2 - Validate with a Trial + Capacity Metrics App: run your actual workloads on the free 60-day trial capacity and monitor consumption using the Fabric Capacity Metrics App. Look at real CU consumption, spot any throttling events, and identify your peak usage periods. This gives you actual data to justify a production SKU purchase rather than a guess.

Admin Portal and Capacity Settings

Capacity Roles

There are two capacity-level roles in Fabric:

• Contributor: can assign and remove workspaces from the capacity. That is it.
• Admin: everything a Contributor can do, plus the ability to change capacity settings, add and remove other Admins and Contributors, configure Surge Protection, set notification thresholds, manage delegated tenant settings, and configure Power BI and Spark workload settings.

Capacity Admin roles for F SKUs are managed in the Fabric Admin Portal under Capacity Settings. The Tenant Admin initially assigns admins through Azure when the capacity is created.

Key Settings

Once you are in the Capacity Settings for an F SKU, there are a few areas worth knowing:

Workspaces: assign and remove workspaces from the capacity. Both Admins and Contributors can do this.

Notifications: configure email alerts when capacity usage exceeds a threshold percentage. Useful for getting ahead of throttling before users start feeling it.

Surge Protection: a setting that limits background operations when your 24-hour background CU window reaches a configured rejection threshold. The idea is to protect interactive users from being throttled out by a wave of background jobs. We will cover this properly in Part 4, but the short version is: enable it and configure thresholds based on your normal background usage patterns.

Preview - Workspace Consumption Limits: a preview feature under Surge Protection that lets you set per-workspace CU thresholds. When a workspace exceeds the configured threshold within a 24-hour window, it gets blocked rather than the entire capacity being throttled. This is a meaningful improvement for multi-team environments where one noisy workspace can impact everyone else.

Workload Settings: configure memory limits for Power BI workloads, Spark pool sizes and starter pool configuration, and whether job-level bursting is enabled for Spark.

Delegated Tenant Settings: allows capacity admins to override tenant-level settings at the capacity level, and grant workspace admins additional permissions beyond what the tenant default allows.

Pause, Resume, and Resize (F SKU Only)

Three operational controls that are unique to F SKUs:

Resize: done in the Azure Portal on the capacity resource. Scaling up raises your CU allowance and throttling thresholds immediately. Scaling down lowers them, which can trigger throttling if you have significant smoothed usage carryforward. Check your current state in the Capacity Metrics App before scaling down. Resizing can also be automated via Fabric REST APIs, Azure Automation, or the Fabric CLI for scheduled scaling patterns.

Pause: stops all running workloads within roughly 10 minutes and blocks new requests. Any smoothed usage debt is reconciled as a one-time pay as you go billing event when the capacity is paused, then the slate is clean on resume. Use it for overnight or weekend cost management, or as a last resort to clear severe throttling quickly.

Resume: brings the capacity back online with zero utilization and zero smoothed usage debt. Workloads can be submitted again immediately.

Key Takeaways

• A capacity is a pre-reserved pool of compute, not a per-job billing meter. You pay for what you provision, not just what runs.
• F SKUs are the right choice for production Fabric workloads. Use pay as you go while you are still learning the right size, then move to a Reservation once you have a stable baseline.
• Region matters more than people expect. Pick your region before you start assigning workspaces.
• The SKU Estimator is a useful starting point, but the Trial and Capacity Metrics App is how you actually validate sizing before spending real money.
• Workspace consumption limits are in preview and worth enabling if you are running a shared capacity across multiple teams.

---

In Part 2, I will walk through the Fabric Capacity Metrics App in detail and explain the difference between interactive and background operations, which is the foundation for understanding everything about consumption, throttling, and optimization.

References

• Manage your Fabric capacity
• Plan your capacity size
• Capacity Planning Overview
• Throttling Policy
• Surge Protection