Co-authored by

How Does Microsoft Fabric Capacity Work?

Quick answer: Microsoft Fabric capacity is a shared pool of Capacity Units (CUs) purchased as F-SKUs, ranging from F2 (2 CUs) to F2048 (2,048 CUs). Every workload in your Fabric tenant — Power BI reports, Data Factory pipelines, Synapse data engineering, real-time analytics, and Copilot queries — draws from this single pool. You pay per CU per hour, either on pay-as-you-go or a committed reservation.

The shift from Power BI Premium P-SKUs to Fabric F-SKUs changed what capacity means. Legacy P-SKUs allocated virtual cores for Power BI specifically. Fabric capacity applies across the entire platform, which means one capacity purchase serves everything from pipeline runs to notebook compute to report rendering. There is no separate allocation per workload type.

CU consumption works on a smoothing model. Interactive operations (report queries, dashboard refreshes) follow a 10-minute smoothing window — a short burst does not immediately trigger throttling; the system averages utilization over that window. Background operations use a 24-hour smoothing window. When sustained utilization exceeds purchased CUs across those windows, Fabric begins queuing requests and eventually throttling.

One P-SKU v-core maps to 8 CUs in the F-SKU model. A Power BI Premium P1 — 8 v-cores — maps to F64 (64 CUs). That equivalence matters when migrating from a legacy Premium environment, covered in our Microsoft Fabric enterprise adoption roadmap.

The F64 Cliff That Changes Everything

Quick answer: At F64 and above, Power BI report viewers need only a free Fabric license — not a $14/month Pro license. Below F64 (F2 through F32), every viewer still needs a paid Pro or PPU license. This creates a cost inversion: a smaller, cheaper capacity tier can cost more than F64 once viewer licenses are counted.

This is the number most Fabric sizing discussions bury. It deserves to come first.

The Worked Example: F32+Pro vs F64

Scenario: your organization has 300 Power BI report consumers and is evaluating Fabric capacity.

At exactly 300 viewers, both options cost almost the same. But with F64:

• Double the compute capacity (64 CUs vs 32 CUs)
• No per-viewer license overhead to track, audit, or renew
• Every additional viewer costs nothing in licensing

At 350 viewers, the comparison shifts:

F64 saves $695/month at 350 viewers, and that gap grows linearly with each new viewer. The breakeven between F32 and F64 (counting Pro licenses) is approximately 300 viewers.

The counterintuitive result: a smaller, cheaper capacity tier can cost more than F64 once viewer licenses are counted. Any sizing conversation that stops at the capacity sticker price is incomplete.

For the full picture on how F64 interacts with Pro and Premium Per User licensing, see our Power BI licensing comparison guide.

What Each F-SKU Tier Is Roughly For

Quick answer: F2–F8 are for proof-of-concept and small data engineering. F64 is the like-for-like P1 replacement and the free-viewer threshold. Above F64, each doubling of CUs roughly doubles cost — scale for compute, not for licensing.

The table below covers commonly deployed tiers. F512, F1024, and F2048 exist for very large multi-tenant platforms and are not covered here.

Monthly PAYG costs calculated at $0.18/CU/hour × 730 hours. Reserved pricing reflects approximately 41% discount for a 1-year Azure commitment. Both are approximations — actual pricing depends on Azure region and commercial agreement. Verify at the Azure Fabric pricing page before budgeting. Prices as of June 2026.

A few notes worth highlighting:

F2 is not a production tier. Two CUs support very light workloads. A single complex DAX query on a composite model can spike utilization to 100% and trigger throttling. F2 is appropriate for Fabric feature testing, developer sandboxes, and running the Fabric Capacity Metrics App itself — not for serving report users.

The 60-day Fabric trial provides F64-equivalent capacity at no cost. Many organizations size based on trial performance and then find production on F2 or F8 behaves very differently. The trial inflates your performance baseline; account for this when planning production capacity.

F64 is the practical entry point for enterprise Power BI. It replaces P1, unlocks free viewers, and gives enough headroom for mixed Power BI and light Fabric workloads. Organizations migrating from P1 Premium capacity land here by default.

Above F64, scale for compute — not licensing. Once you are at F64 or higher, viewer licensing is resolved. Sizing decisions above F64 are about whether your CU pool can handle concurrent workloads without sustained throttling.

A Sizing Method That Does Not Overbuy

Quick answer: Run the F64 viewer math first to make the licensing decision, then start PAYG, load test with real workloads, monitor the Fabric Capacity Metrics App, right-size, and then commit to a reservation. Skip any of these steps and you will either oversize or undersize.

The most common sizing mistake is picking a number in a procurement conversation. Here is a structured alternative:

1. Run the viewer math first. Multiply your current viewer count by $14 (Pro license rate as of 2026). If that product approaches or exceeds $4,205/month (the difference between F32 and F64), you should start at F64 regardless of compute requirements. This decision is arithmetic. It does not require a load test or architecture review.

2. Start on pay-as-you-go. Do not commit to a reservation before measuring production utilization. PAYG lets you pause capacity during off-hours — nights, weekends, and extended low-use periods — without billing impact. A PAYG capacity that runs 18 hours per day, 5 days a week reduces effective monthly cost by roughly 35–45% vs. always-on.

3. Load test with real workloads. Deploy your actual Power BI reports, pipeline schedules, and notebook jobs. Synthetic benchmarks and demonstration datasets do not replicate production CU consumption. Run for a representative week before drawing conclusions.

4. Monitor the Fabric Capacity Metrics App. This is the primary tool for observing CU utilization against purchased capacity. Install it from AppSource and connect it to your Fabric capacity. Look for:

   • Sustained utilization above 80% of purchased CUs — a signal to upsize
   • Frequent throttling events during business hours — confirms the capacity is undersized for the load
   • Average utilization below 30% with occasional spikes — the smoothing window may be absorbing bursts and you may be correctly provisioned, or you have room to downsize

5. Right-size, then reserve. After 4–8 weeks of production monitoring, your utilization pattern is clear. If average utilization sits between 40–70%, you are likely at an appropriate tier. If you are consistently above 80%, upsize before committing. Once the baseline is stable, buy a 1-year reservation — approximately 40% savings over PAYG at the same tier.

For an enterprise rollout with multiple workloads and teams, the capacity planning phase is part of a broader adoption sequence. Our Power BI licensing cost optimization guide covers the cost levers available across the full licensing stack.

Cost Traps When Committing to Fabric Capacity

Quick answer: Reserved capacities continue billing through pauses. Scaling below a reservation does not reduce the bill. Overage protection is capped at roughly 3× your purchased CUs, not unlimited. Copilot in Fabric and Power BI draws from the same CU pool.

These are the four surprises that most commonly appear after signing a reservation.

Reserved Capacity Keeps Billing Through Pauses

A PAYG capacity that you pause stops billing. A reserved capacity does not. If you purchase a 1-year F64 reservation and then pause the capacity for two weeks — project pause, extended leave, Ramadan, maintenance window — you continue paying the reserved rate for those two weeks. The reservation commitment is non-refundable.

Mitigation: model your utilization calendar before committing. If you anticipate extended periods of low use, factor in whether a PAYG tier with pausing saves more than the reservation discount provides.

Scaling Below a Reservation Does Not Lower the Bill

If you purchase an F128 reservation and later scale the running capacity down to F64 in the Azure portal, you still pay the F128 reserved rate. The reservation locks your billing at the purchased tier. Scaling the running capacity below the reservation changes compute availability, not cost.

The practical rule: right-size first, then reserve. Do not over-reserve under the assumption you can scale down the bill later.

Overage Protection Is Not Unlimited

Fabric's overage protection allows capacity to absorb burst demand above purchased CUs — up to approximately 3× the purchased amount for short durations, smoothed over time. This is a buffer for genuine spikes, not a substitute for correctly-sized capacity. Sustained utilization beyond the smoothing window leads to throttling, queued requests, and eventually failed interactive operations.

Copilot Draws from Your CU Pool

Microsoft Copilot features in Power BI and Fabric — including Copilot for report generation, notebook AI, and AI Skills — draw CUs from your Fabric capacity. Copilot has billed against the capacity CU pool since 2024 (rates have since been reduced twice), so treat its consumption as a permanent line item in your sizing, not an optional extra.

This matters specifically at F64: a capacity running Power BI workloads at 60–70% CU utilization will see that headroom erode as Copilot adoption increases. Monitor Copilot consumption in the Fabric Capacity Metrics App under the AI workload category. For GCC enterprises evaluating Copilot readiness, our Power BI Copilot enterprise readiness post covers the prerequisites and realistic CU expectations.

Frequently Asked Questions

Q: Which Fabric SKU do I need?

Start with the viewer math: multiply your Power BI viewer count by $14. If that number approaches $4,205 (the PAYG cost gap between F32 and F64), start at F64. If your viewer count is small — under 100 — and compute workloads are light, F16 or F32 with Pro licenses may be more economical. If you are migrating from Power BI Premium P1, the like-for-like replacement is F64. Do not trust a sizing recommendation that skips the viewer license arithmetic.

Q: Is F2 enough for Power BI?

No, not for production report serving. F2 provides 2 CUs — enough to test Fabric features or run the Capacity Metrics App, not enough to serve concurrent report users without constant throttling. A single Power BI composite model with a handful of concurrent users can saturate F2. The practical minimum for a small production team is F8; for any meaningful viewer audience with Pro licensing, F32 or F64.

Q: How much does F64 cost?

Approximately $8,410/month on pay-as-you-go at US East rates, calculated at $0.18/CU/hour × 64 CUs × 730 hours. A 1-year Azure reservation reduces this by approximately 40%, to around $5,046/month. Regional pricing varies by 10–15%. Verify current rates at the Azure Fabric pricing page before building a budget. Figures as of June 2026.

Q: Can I pause Fabric capacity to save money?

On a pay-as-you-go capacity, yes — pausing stops billing immediately and resumes when you restart. Organizations that pause overnight and over weekends typically reduce effective monthly cost by 35–45%. On a reserved capacity, no — the reservation billing runs continuously regardless of pause state. This is one reason to stay on PAYG until you have confirmed your production utilization pattern. Once you know the right tier and have measured your utilization calendar, a reservation makes sense.