At FabCon 2026 , Microsoft introduced Capacity Overage in preview, a feature that lets organizations pay for excess compute instead of getting throttled. The fact that Microsoft built this tells you something. Throttling had become one of the most common complaints from Fabric administrators. Community forums and Reddit threads were full of teams reporting 20-second delays on dashboard loads, rejected queries during peak hours, and capacity frozen for days after a runaway Spark job.
Most of those problems trace back to the same root cause. The team picked the wrong Microsoft Fabric capacity size, skipped monitoring, or did not understand how Fabric shares compute across workloads.
From what we have seen in preview, Capacity Overage is most useful for organizations that have predictable weekday spikes but cannot justify the next SKU tier. It does not replace right-sizing. But it softens the penalty for underestimating peak demand and gives administrators a budget-controlled safety net instead of hard throttling.
In this article, we’ll cover what Microsoft Fabric capacity is, how Capacity Units work, which SKU fits different workload sizes, how billing and resource management play out in practice, and how to plan a capacity strategy that scales with your organization.
Key Takeaways What Microsoft Fabric capacity is and how it works as a shared compute pool How SKU tiers map to different workload sizes and why the F64 threshold matters for licensing Smoothing, bursting, and throttling work together to manage performance under load The Fabric Capacity Metrics App and SKU Estimator help teams right-size their capacity based on real usage data Capacity planning should start with a free trial, move through a pilot phase, and scale to production only when utilization data supports it Microsoft Fabric capacity is a shared pool of compute resources, measured in Capacity Units (CUs), that powers every workload on the platform. Data pipelines , Spark notebooks, warehouse queries, and Power BI reports all draw from this same pool. The size of the pool, determined by the SKU tier an organization purchases, controls how many operations can run concurrently and how fast they execute.
What Microsoft Fabric Capacity Means for Your Organization Microsoft Fabric is a unified analytics platform that brings data engineering, data warehousing , data science, real-time intelligence, and Power BI together into one environment. Instead of managing separate tools with separate billing, teams work inside a single environment backed by OneLake as the shared storage layer.
What makes Fabric different from older setups is how it handles compute. Every workload on the platform pulls from one shared resource pool called a capacity. That pool’s size directly affects whether teams work smoothly or spend half their morning waiting on throttled reports. Getting familiar with how this pool works makes every downstream decision, from SKU selection to workspace governance, a lot easier to get right.
1. Fabric Replaces Separate Compute Silos with One Shared Pool Before Fabric, most data platforms charged separately for each service. Compute for a Spark cluster, a data warehouse , and a BI tool each had its own billing meter and its own scaling rules. Fabric consolidates all of that into one resource pool.
That pool is what Microsoft calls a capacity. Every workspace in a Fabric tenant sits on a capacity, and every operation, whether it is an interactive report query or a background pipeline refresh, draws compute from it. The result is simpler billing but a different kind of planning challenge. Teams now compete for the same finite set of resources.
2. Capacity Units Work as the Single Compute Currency A Microsoft Fabric CU (Capacity Unit) bundles CPU, memory, disk I/O, and network bandwidth into one billing metric. The more CUs an organization purchases, the more concurrent workloads it can run and the faster those workloads execute.
Each Fabric workload consumes CUs at a different rate. A Power BI report query uses CUs differently than a Spark notebook or a Data Factory pipeline . Microsoft measures consumption in 30-second evaluation cycles , and the total CU usage across all workloads gets measured against the SKU’s allocation.
This shared model creates efficiency. When a Spark job finishes, those freed CUs become available for a warehouse query or a report refresh. But it also means that a heavy Spark job running at the same time as a large data refresh can slow both down if the total exceeds the SKU’s capacity.
3. Tenants, Capacities, and Workspaces Form a Three-Layer Hierarchy Understanding this hierarchy matters for capacity planning because it determines who competes for resources and where isolation boundaries sit. (For how this structure fits into Fabric’s broader technical architecture, see our Fabric architecture guide .)
Microsoft Fabric’s architecture uses a three-layer structure that determines how resources get allocated.
Tenant is the top-level container, tied to a Microsoft Entra ID instance. An organization typically has one tenant, though some create separate tenants for compliance or regional reasons.Capacity sits inside a tenant. Each capacity is a distinct resource pool with its own SKU size. A tenant can have multiple capacities, and organizations often split them by department, workload type, or criticality tier.Workspace lakehouses , pipelines, reports, and notebooks. Each workspace gets assigned to a capacity, and the items inside it consume CUs from that capacity.This hierarchy gives administrators control over who uses what resources. Finance can have its own capacity isolated from Marketing. Production workloads can sit on a larger SKU while development stays on a smaller one.
Which Microsoft Fabric SKU Size Fits Your Workload Microsoft organizes Fabric capacity into Fabric F SKU tiers that roughly double in compute power at each level. Picking the right SKU depends on workload mix, user count, concurrency needs, and data volume.
1. F8 Through F512+ and the Compute Power at Each Tier SKU Capacity Units (CUs) Typical Use Case F8 8 Department-level BI and light data engineering F64 64 Enterprise starting point, removes per-viewer licensing F128 128 Multi-team production with heavy concurrency F512+ 512 to 2048 Large enterprise with high concurrency and real-time processing
For the full SKU-by-SKU breakdown with pricing at each tier, see our Microsoft Fabric pricing guide .
2. Why the F64 Threshold Changes Your Licensing Math F64 is the most important SKU decision point in Fabric. Below F64, every user who views Power BI content needs a Power BI Pro license ($10/user/month). At F64 and above, that per-user cost drops to zero for report viewers.
For organizations with hundreds of report viewers, the licensing savings alone can justify the jump to F64, even if the workload would technically fit on F32. F64 also opens access to larger dataset sizes, faster refresh rates, and advanced features. For most enterprises moving from Power BI Premium to Fabric , F64 is the natural starting point because it closely maps to the retired P1 SKU.
For detailed licensing math and a side-by-side cost comparison across all tiers, see our Fabric pricing guide .
How Microsoft Fabric Bills for Capacity Usage Once the right SKU size is clear, the next decision is how to pay for it. Fabric’s billing model works differently from traditional per-service Azure pricing, and the two main options create very different cost profiles depending on usage patterns.
1. Choosing Between Pay-as-You-Go and Reserved Billing Pay-as-you-go (PAYG) charges an hourly rate, billed per second with a one-minute minimum. Organizations can pause, resume, and resize their capacity at any time. If the capacity is paused on weekends and evenings, the bill drops to zero for those hours.
Reserved capacity locks in a one-year or three-year commitment at a discounted rate. Microsoft puts the discount at roughly 41% compared to PAYG in most regions for a one-year reservation. But reserved capacity cannot be paused, since the commitment runs continuously.
Most organizations start with PAYG during pilots and initial rollout. Once usage patterns stabilize and the SKU size proves right, switching to reserved capacity locks in significant savings. Some take a hybrid approach, running a reserved base capacity and adding a second PAYG capacity for burst periods like quarter-end reporting.
From our deployments, the typical switch point is 8 to 12 weeks after production go-live. By then, utilization data from the Metrics App gives a clear picture of steady-state demand, and the team can commit with confidence. For a detailed cost comparison of PAYG vs reserved pricing at each SKU tier, see our Fabric pricing guide .
2. How Smoothing, Bursting, and Throttling Affect Real-World Costs Fabric applies three mechanisms that directly affect how capacity behaves under load .
Smoothing spreads CU consumption over a longer evaluation window rather than measuring it at peak. A workload that spikes to 10x the CU limit for a few seconds does not trigger throttling if the average over the smoothing window stays within bounds. This lets smaller SKUs handle short bursts effectively.Bursting allows individual operations to temporarily use more CUs than the SKU’s steady-state allocation. Short-lived tasks like a quick Spark job can burst above the CU limit and finish faster, with the accounting smoothed over time.Throttling kicks in when sustained demand exceeds the capacity limit even after smoothing. Background operations get delayed first. If overload continues, interactive operations (report queries, dashboard loads) also slow down or get rejected.For Spark-heavy workloads specifically, Microsoft now offers Autoscale Billing for Spark as an opt-in feature. It runs Spark jobs on dedicated serverless resources outside the shared capacity pool, so heavy notebook runs do not eat into CUs that Power BI and warehouse queries need. Admins can set maximum CU limits to control costs.
The practical takeaway is that smoothing and bursting make Fabric more forgiving than a strict CU-per-second model would suggest. A workload that occasionally spikes above the limit can run fine on a smaller SKU. But sustained high usage still requires a bigger SKU or a second capacity to avoid throttling.
How to Plan the Right Fabric Capacity for Your Workloads Fabric capacity planning follows a phased approach. Microsoft’s own guidance recommends starting small, measuring actual usage, and scaling deliberately.
1. Starting with Trial Capacity and Scaling from POC to Production Microsoft provides a free 60-day trial capacity , configured as either F4 or F64. This trial gives teams access to all Fabric workloads, up to 1 TB of OneLake storage, and the Capacity Metrics App for monitoring.
The recommended progression through capacity planning follows a clear path.
Phase Capacity Type SKU Range Duration Goal POC Free trial F4 or F64 2 to 4 weeks Validate use case, measure baseline CU usage Pilot PAYG F8 to F16 4 to 8 weeks Expand users, test concurrency, validate SKU Production PAYG or Reserved F32 to F128+ Ongoing Full workload at optimized cost
Phase 1 (POC on trial) means keeping the scope narrow with a single use case , a small dataset, and a handful of users. Run representative workloads and measure CU consumption through the Metrics App.Phase 2 (Pilot on PAYG) means purchasing a small PAYG capacity (F8 or F16), migrating the POC workloads, and expanding the user base. Monitor utilization over 2 to 4 weeks to validate the SKU size.Phase 3 (Production) means scaling to the right SKU based on pilot data. If utilization consistently runs above 70 to 80% during peak, scale up. If it stays below 40%, consider a smaller SKU or consolidating workloads.The trial data is the foundation for every subsequent SKU decision. Skipping it and guessing at a production SKU is how organizations end up overpaying or hitting performance walls in the first month.
How Kanerika Approaches Capacity Sizing for New Deployments From 100+ Fabric deployments, we have found that a few patterns hold across industries. Teams with fewer than 20 concurrent BI users and light Spark usage can start safely on F8. Once interactive query volume exceeds 50 concurrent sessions or Spark notebooks run daily, F64 becomes the practical floor.
For organizations running mixed workloads (daily pipeline refreshes, concurrent BI dashboards, and periodic Spark training jobs), we baseline utilization for 2 weeks before making any SKU recommendation. One mid-market logistics client running 12 daily pipeline refreshes and 80 concurrent Power BI viewers stabilized at 68% CU utilization on F64 within three weeks of going live. That headroom was enough to absorb quarter-end reporting spikes without throttling.
The biggest mistake we see is teams sizing capacity based on the data volume rather than the concurrency pattern. A 5 TB dataset that serves 10 analysts on a scheduled refresh needs far less CU than a 500 GB dataset serving 200 concurrent dashboard viewers. Concurrency, not storage, is what drives SKU selection.
2. Using the Fabric Capacity Metrics App and SKU Estimator to Right-Size The Fabric Capacity Metrics App is the primary monitoring tool for capacity administrators. It provides 14 days of utilization data broken down by workload type, item, and operation.
[Image: Screenshot of the Fabric Capacity Metrics App utilization dashboard | Alt text: Microsoft Fabric Capacity Metrics App showing CU utilization trends and throttling events over 14 days]
The app tracks several signals that matter for right-sizing.
CU utilization over time shows whether the capacity runs consistently near its limit or has significant headroomThrottling events reveal when the capacity hit its ceiling and started delaying or rejecting operationsTop-consuming items identify which specific notebooks, pipelines, or reports drive the most CU usageInteractive vs background split shows how much compute goes to real-time user queries versus scheduled jobsMicrosoft also offers the Fabric SKU Estimator in preview. Teams input their expected workloads, data sizes, and usage patterns, and the tool suggests an approximate SKU. It is a starting point for budgeting but not a substitute for measuring real consumption through the Metrics App.
When to Scale Up vs Scale Out in Microsoft Fabric When a capacity starts showing strain, Fabric capacity management comes down to two options. Scaling up means moving to a bigger SKU. Scaling out means adding a second capacity and splitting workloads across them.
1. When a Bigger SKU Solves the Problem vs When You Need a Second Capacity Scaling up is simpler. One bigger pool serves everything, and all workloads benefit from the additional compute. But SKU sizes double at each tier, so moving from F32 to F64 doubles the cost. There is no F48.
Scaling out is more flexible. Moving Finance to its own F32 while keeping everything else on the original capacity isolates workloads and makes cost attribution cleaner. But it also means managing two capacities, two monitoring dashboards, and two sets of governance rules.
Factor Scale Up Scale Out Simplicity One capacity, one set of rules Multiple capacities to manage Cost control Doubles at each tier More granular sizing per team Isolation All workloads share resources Workloads isolated by capacity When to use Uniform workload growth across teams One team’s usage dominates or needs isolation
2. How to Handle the Noisy Neighbor Problem The “noisy neighbor” problem occurs when one team or workload consumes a disproportionate share of a shared capacity. A data engineering team running heavy Spark transformations at 9 AM can throttle the Power BI dashboards that the executive team opens at the same time.
Several strategies help prevent this.
Dedicated capacities for high-consumption workloads give full isolation but increase total spendWorkspace-level governance Scheduling background jobs (pipeline refreshes, model training ) outside peak interactive hours reduces contentionSurge protection automatically rejects background jobs when capacity is under stress, preserving interactive performanceChargeback reporting through the Fabric Chargeback App attributes consumption to specific teams, creating accountabilityFor most mid-market organizations, a combination of scheduling discipline and surge protection handles the noisy neighbor issue without requiring separate capacities for every team.
Capacity Planning Mistakes Most Teams Make in Fabric Knowing how to size, bill, and scale a capacity is the full toolkit. But even teams that get the fundamentals right still trip on a few predictable mistakes. The most expensive ones happen at the sizing stage.
Starting too large happens when teams buy F64 for a pilot that only needs F8. The unused capacity costs real money every month, and it gives a false sense of how the workload will behave at scale because nothing ever throttles.Starting too small happens when teams pick F2 or F4 for a production workload with 50 concurrent users. Throttling hits immediately, and users lose confidence in the platform before it has a fair chance.Skipping the F64 evaluation leaves money on the table. If the workload needs F32 and there are 100+ Power BI viewers each paying $10/month for Pro licenses, F64 might cost less in total.1. Operational Oversights That Inflate Costs Over Time Sizing gets the most attention, but ongoing operational gaps are just as costly over time.
Ignoring the Metrics App means flying blind. Without utilization data, every scaling decision is a guess. Installing the Metrics App on day one should be non-negotiable.Not separating dev from production leads to development workloads consuming CUs that production needs. A small PAYG capacity for dev/test protects production SLAs.Forgetting OneLake storage costs is common because teams focus entirely on compute. OneLake charges roughly $0.023 per GB/month, and it adds up as data accumulates. Pausing a capacity does not pause storage billing.
How SSMH Built a Unified Analytics Foundation on Microsoft Fabric Southern States Material Handling (SSMH), one of the largest TOYOTAlift dealers in the U.S., faced a common enterprise challenge. Operational data lived in disconnected systems, and leadership relied on manually compiled reports that lagged behind the business.
Kanerika worked with SSMH to build a unified analytics platform on Microsoft Fabric and Power BI . The project involved designing the workspace architecture , structuring the Lakehouse layer , and configuring capacity to support both real-time operational dashboards and batch analytics workloads running from the same resource pool.
The result gave SSMH’s leadership team direct access to operational insights without waiting for manual reports. As Delano Gordon, CIO at SSMH, put it, Kanerika’s flexibility in aligning Fabric with their business needs ensured they were building a system that drives better results across operations.
For a capacity planning perspective, the SSMH engagement shows what a well-architected Fabric deployment looks like in practice. Workspace design , Lakehouse structure, and capacity sizing all had to align so that concurrent BI queries and data processing jobs would not compete for CUs during peak hours.
How Kanerika Helps Enterprises Plan and Optimize Microsoft Fabric Capacity Capacity planning is not just a technical exercise. It requires understanding workload patterns, growth projections, licensing math, and governance requirements. That is where working with a Microsoft Fabric Featured Partner adds real value.
Kanerika is a Microsoft Solutions Partner for Data and AI with the Analytics Specialization. As a Microsoft Fabric Featured Partner , Kanerika has been one of the earliest companies to deploy Fabric in production environments across industries.
During onboarding, Kanerika’s Fabric team installs the Capacity Metrics App, configures workspace-level throttling alerts, and runs a 2-week utilization baseline before making any SKU recommendations. That baseline captures concurrency patterns, peak-hour CU consumption, and the interactive-to-background workload split, which are the three inputs that determine whether the initial SKU fits or needs adjustment.
For organizations migrating from legacy platforms like Azure Data Factory , SSIS , SQL Services , or Informatica , Kanerika’s FLIP Migration Accelerator reduces migration effort by 75% and completes transitions in 2 to 8 weeks depending on complexity. Post-migration, Kanerika helps right-size the Fabric capacity based on actual workload data , ensuring teams are not overpaying or underprovisioning.
With 100+ enterprise clients, a 98% retention rate, and a 5.0/5.0 rating on GoodFirms, Clutch, and Capterra , Kanerika brings both deep Fabric expertise and a track record of production-grade deployments.
Wrapping Up Microsoft Fabric capacity is the foundation that determines how fast workloads run, how many users can work simultaneously, and how much the platform costs. Getting it right requires measuring real usage, not guessing. Start with a trial , use the Metrics App from day one, and scale deliberately through POC and pilot phases before committing to a production SKU. The F64 threshold deserves special attention for its licensing implications. And for organizations migrating to Fabric or scaling beyond initial deployments, working with a partner like Kanerika shortens the path from planning to production
Frequently Asked Questions Microsoft Fabric capacity is a shared pool of compute resources measured in Capacity Units (CUs). All Fabric workloads, including data pipelines , Spark notebooks, warehouse queries, and Power BI reports, draw from this same pool. Organizations purchase capacity through F-SKU tiers that determine how much compute power is available for concurrent operations.
How do Capacity Units (CUs) work in Microsoft Fabric? CUs bundle CPU, memory, disk I/O, and network bandwidth into one metric. Every Fabric operation consumes CUs while running. Microsoft measures usage in 30-second evaluation cycles and applies smoothing to spread consumption over time. Higher CU allocations mean more concurrent workloads and faster execution across the platform.
What is the difference between F-SKUs and P-SKUs? How much does Microsoft Fabric capacity cost? Cost varies by SKU tier and billing model. F2 starts at approximately $262/month on pay-as-you-go. F64, the most common enterprise starting point, runs around $8,400/month on PAYG. Reserved one-year commitments reduce costs by roughly 41%. For detailed pricing, see Kanerika’s Microsoft Fabric pricing guide.
What happens when a Fabric capacity gets throttled? Throttling occurs when sustained CU consumption exceeds the capacity limit after smoothing is applied. Background operations like scheduled refreshes get delayed first. If overload continues, interactive operations such as report queries and dashboard loads also slow down or get rejected. Scaling up the SKU or moving workloads to a second capacity resolves persistent throttling.
How do I monitor Microsoft Fabric capacity utilization? The Fabric Capacity Metrics App is the primary monitoring tool. It provides 14 days of utilization data broken down by workload type, item, and operation. Capacity administrators use it to track CU usage trends, identify throttling events, and spot which items consume the most compute. Installing this app should be the first step after provisioning any capacity.
Should I use pay-as-you-go or reserved capacity for Fabric? Start with pay-as-you-go during pilot and early production phases. PAYG lets you pause, resize, and adjust without commitment. Once workloads stabilize and the SKU size proves right, switch to a one-year reserved instance for roughly 41% savings. Some organizations run a reserved base capacity plus a PAYG capacity for handling seasonal spikes.
Can Kanerika help with Microsoft Fabric capacity planning? Yes. As a Microsoft Fabric Featured Partner and Solutions Partner for Data and AI, Kanerika helps enterprises plan , deploy, and optimize Fabric capacity. This includes workload assessment, SKU right-sizing, migration from legacy platforms using the FLIP Accelerator, and ongoing capacity monitoring and governance. Book a consultation to start the conversation.
