Microsoft Fabric Capacity Units (CUs) Explained: 2026 Sizing Guide

Microsoft Fabric bills capacity by "Capacity Units" (CUs), a fabricated (pun intended) currency unit that measures compute consumption across every Fabric workload — Power BI, warehouses, lakehouses, notebooks, Data Factory pipelines, Real-Time Intelligence, and Copilot. If you are buying a Fabric F-SKU without understanding CUs, you are either overspending or heading for a throttling incident. This guide explains what CUs actually measure, how they map to F-SKUs, what each workload consumes, and provides a sizing framework backed by real enterprise benchmarks.

What Is a Capacity Unit (CU)?

A Capacity Unit is Microsoft's abstract unit of compute in Fabric. One CU is roughly equivalent to a specific amount of underlying compute resources — CPU seconds, memory allocation, and I/O operations — normalized across every Fabric workload. A CU is not a wall-clock second; it is a compute-second measured against Microsoft's internal capacity model.

The critical numbers to memorize:

• F2 SKU = 2 CU of capacity available continuously (2 CU-seconds per second)
• F64 SKU = 64 CU — the pivot SKU that unlocks free Pro-viewer access
• F2048 SKU = 2048 CU — the top-tier enterprise SKU

Each F-SKU number equals its base CU allocation. So an F64 continuously provides 64 CU-seconds per second, or 64 × 3600 × 24 × 30 = ~166 million CU-seconds per month at full utilization. In practice, you never operate at 100% utilization — 60-70% average is a healthy target with 30% headroom for spikes.

How CUs Map to F-SKUs and Cost

The full 2026 US-list Fabric F-SKU catalog (pay-as-you-go per-month):

Reserved capacity discounts are 40% for a 1-year commitment. If you know you need Fabric for at least 12 months, reserved capacity is always the correct choice — the discount is significant and there is no lock-in penalty at renewal.

What Each Fabric Workload Consumes in CUs

Approximate CU consumption per workload operation (2026 measured across enterprise deployments):

Power BI (Direct Lake / Direct Lake+ semantic model)

• Simple aggregation query: 0.05 - 0.15 CU-seconds per query
• Complex time-intelligence query: 0.20 - 0.50 CU-seconds
• Report page load (5 visuals): 0.5 - 1.5 CU-seconds
• Semantic model refresh (Import mode, 10 GB dataset): 200 - 400 CU-seconds
• Semantic model refresh (Direct Lake — no refresh needed): 0 CU

Power BI (Copilot in agent mode)

• Insights Agent invocation: 8 - 15 CU-seconds
• DAX Agent (measure generation): 12 - 20 CU-seconds
• Report Design Agent (page layout generation): 20 - 40 CU-seconds
• Data Model Agent (schema review): 10 - 18 CU-seconds

Fabric Warehouse

• Small query (< 1 GB scanned): 5 - 20 CU-seconds
• Medium query (1-10 GB scanned): 30 - 120 CU-seconds
• Large analytical query (100 GB scanned): 500 - 2000 CU-seconds

Fabric Lakehouse

• Spark SQL query on Delta table: 8 - 40 CU-seconds
• PySpark notebook cell execution (5-min job): 200 - 800 CU-seconds
• Autoloader Streaming ingest (per hour): 400 - 1200 CU-seconds

Real-Time Intelligence

• Eventstream ingest (per 1M events): 100 - 300 CU-seconds
• KQL query (small): 2 - 10 CU-seconds
• Real-Time Dashboard refresh: 5 - 20 CU-seconds per refresh interval
• Data Activator trigger evaluation (per 1000 events): 2 - 8 CU-seconds

Data Factory

• Pipeline execution (10 activities, medium data volume): 100 - 300 CU-seconds
• Dataflow Gen2 refresh (1 GB source): 200 - 500 CU-seconds
• Copy Data activity (10 GB): 60 - 180 CU-seconds

Fabric SQL Database

• OLTP transaction (single-row insert): 0.01 - 0.05 CU-seconds
• Point-lookup query: 0.02 - 0.10 CU-seconds
• Complex analytical query on OLTP schema: 30 - 120 CU-seconds

The 24-Hour Smoothing Window

Fabric implements a rolling 24-hour smoothing window. When you exceed your capacity's CU/second budget in a peak minute, Fabric borrows against the next 24 hours of budgeted CU. This is why occasional spikes do not immediately throttle you — the smoothing absorbs them. What throttles you is sustained consumption above capacity. If you consume 130% of your F64 (~83 CU/sec average) for hours, the smoothing exhausts and Fabric starts throttling (delaying operations or rejecting new requests).

Practical implication: buy a capacity such that your average load is 60-70% of capacity, and your peak hourly load stays under 130%. That balance keeps smoothing effective and avoids user-facing throttling incidents.

CU Sizing Framework by Workload Profile

Enterprise sizing by workload type (empirical guidance from real deployments):

Small BI-only workload (100-500 Pro-equivalent users)

• Power BI Import semantic models, moderate refresh frequency
• 20-50 reports, 1000-3000 report views/day
• Recommended: F32 to F64 ($4,200-$8,400/mo pay-as-you-go)

Medium BI + light data engineering (500-2000 users)

• Mix of Import and Direct Lake+ semantic models
• Fabric warehouse for one BI subject area, Bronze/Silver medallion in Lakehouse
• 50-150 reports, 5000-15000 report views/day
• Recommended: F64 to F128 ($8,400-$16,800/mo pay-as-you-go)

Enterprise BI + full data engineering + real-time (2000+ users)

• Full medallion Bronze/Silver/Gold, multiple Warehouses, Real-Time Intelligence
• Notebook workloads for data science
• Copilot enabled tenant-wide
• 200+ reports, 30000+ report views/day
• Recommended: F256 to F512 ($33K-$67K/mo pay-as-you-go)

Enterprise + Copilot-heavy + Data Agents in production

• All of the above, plus Fabric Data Agent API embedded in customer-facing apps
• Heavy Copilot agent-mode usage by BI teams
• Recommended: F512 to F1024 ($67K-$134K/mo pay-as-you-go)

The CU Calculator Framework

To estimate your CU consumption for a specific workload, use this formula:

Monthly CU-hours = Σ (operation_type × frequency × avg_CU-seconds ÷ 3600)

Example: 5,000 semantic model queries per day at 0.20 CU-seconds each: - Daily CU-seconds: 5,000 × 0.20 = 1,000 CU-seconds - Monthly CU-seconds: 1,000 × 30 = 30,000 CU-seconds - Monthly CU-hours: 30,000 / 3600 = ~8.3 CU-hours

Repeat for every workload type in your environment, sum, divide by 720 (hours per month) to get average CU/second consumption. That number should be under 60-70% of your F-SKU's capacity.

Where to Monitor CU Consumption

Capacity Metrics App: Microsoft ships the Capacity Metrics App (free, install from AppSource) that shows per-item CU consumption over rolling 14-day windows. This is the primary tool for capacity planning and throttling investigation. Key views:

• Overview — total CU % over time, highlighting spikes
• Per-item breakdown — which semantic models, warehouses, notebooks are the biggest consumers
• Throttling events — timeline of any throttling incidents with the responsible items

Fabric Admin center → Monitoring Hub (Build 2026 GA) — real-time capacity monitoring with drill-down to specific operations. This is the newer, more actionable interface.

Fabric admin log via Log Analytics — for programmatic monitoring and integration into your existing observability stack.

Common CU Sizing Mistakes

Mistake 1: Buying for peak, not average. F-SKU cost scales linearly with capacity — a doubled SKU costs 2x. Buy for the 70th percentile of your daily load, not the 99th percentile. Smoothing handles the spikes.

Mistake 2: Forgetting Copilot CU. Enabling Copilot tenant-wide without measuring usage can add 30-50% to CU consumption. Pilot Copilot with a limited user group first, measure the CU cost, then scale.

Mistake 3: Under-sizing for Direct Lake+. Direct Lake+ eliminates refresh CU but shifts consumption to query time. A workload with heavy report views may use more query-time CU than the equivalent Import-mode refresh — model this before migrating.

Mistake 4: Not using reserved capacity. 40% discount for 1-year commit is significant. Any workload with >12 months forward visibility should use reserved.

Mistake 5: Ignoring the 24-hour smoothing window. Some capacity planners size for peak-minute load; that is over-sizing. Fabric smoothing absorbs short spikes. Size for peak-hour or peak-15-min instead.

When to Move Up to the Next SKU

Signal to upgrade to the next F-SKU:

• Average CU utilization consistently > 75% for 2+ weeks
• Throttling events > 1 per week for the same time-of-day
• New workload coming online (e.g., adding Copilot, adding a new business unit) that projections show will push utilization over 80%
• Peak-hour utilization > 150% sustained (smoothing running dry)

Signal to downgrade to a smaller SKU:

• Average CU utilization < 30% for 30+ days
• Zero throttling events for 60+ days AND peak-hour utilization consistently < 60%
• Reserved capacity renewal coming up and current usage does not justify committed size

Related Guides

• Microsoft Fabric vs Power BI Premium: 2026 Break-Even Analysis
• Fabric Capacity Cost Optimization Playbook
• Power BI Copilot Agent Mode: Enterprise Deep-Dive
• Microsoft Fabric Consulting Services

Ready to right-size your Fabric capacity? Book a 30-minute CU sizing review and we will model your specific workload against F-SKU cost.