Fabric Administration and Cost Management: Capacity Units, Throttling, Smoothing, Monitoring, Pause and Resume, and Optimizing Your Fabric Spend

You have built the lakehouses, warehouses, notebooks, and pipelines. Everything works in development. Then the bill arrives: “Fabric capacity usage: 85% consumed. Throttling applied. Pipeline runs delayed by 30 minutes.”

Understanding HOW Fabric charges, WHAT consumes capacity, and HOW to optimize cost is the difference between a well-managed platform and an unexpected budget overrun. This post covers everything a data engineer and admin needs to know about Fabric capacity, cost, and optimization.

Think of Fabric capacity like a hotel with a fixed number of rooms (CUs). Guests (workloads) check in and use rooms. If all rooms are full (capacity exhausted), new guests wait in the lobby (throttling). The hotel manager (admin) must balance occupancy — too few guests wastes money, too many creates delays. This post teaches you to be an effective hotel manager.

Table of Contents

• What Are Capacity Units (CUs)?
• F-SKUs vs P-SKUs
• How Workloads Consume CUs
• CU Consumption by Workload Type
• Throttling: What Happens When Capacity Is Exceeded
• Smoothing: How Fabric Spreads the Load
• The Burst and Smoothing Model Explained
• Monitoring Capacity Usage
• Microsoft Fabric Capacity Metrics App
• Admin Portal Monitoring
• Pause and Resume Capacity
• When to Pause
• Autoscale
• Cost Optimization Strategies
• Right-Size Your Capacity
• Optimize Notebook and Spark Usage
• Optimize Pipeline Scheduling
• Use Starter Pools
• Optimize Delta Tables (OPTIMIZE, V-Order)
• Avoid Unnecessary Refreshes
• F-SKU Sizing Guide
• Real-World Cost Scenarios
• Scenario 1: Small Team (5 engineers, 10 analysts)
• Scenario 2: Medium Enterprise (20 engineers, 50 analysts)
• Trial and Pay-As-You-Go Options
• Common Mistakes
• Interview Questions
• Wrapping Up

What Are Capacity Units (CUs)?

A Capacity Unit (CU) is Fabric’s universal compute currency. Every operation — notebook run, pipeline execution, SQL query, Power BI refresh, Dataflow Gen2 run — consumes CUs. Your Fabric capacity has a fixed number of CUs per second.

Capacity: F64 (64 CU seconds per second)
  → Can process 64 CU-seconds of work every second
  → If a notebook needs 32 CUs for 10 seconds = 320 CU-seconds
  → The F64 can run this notebook while still having 32 CUs for other work

F-SKUs vs P-SKUs

SKU	CUs	Price (approx/month)	Includes Power BI?	Best For
F2	2	~$262	No	Dev/test, learning
F4	4	~$524	No	Small team dev
F8	8	~$1,048	No	Small production
F16	16	~$2,096	No	Medium workloads
F32	32	~$4,192	No	Medium-large
F64	64	~$8,384	Yes (P1 equivalent)	Enterprise
F128	128	~$16,768	Yes (P2 equivalent)	Large enterprise
F256	256	~$33,536	Yes (P3 equivalent)	Very large
F512	512	~$67,072	Yes (P4 equivalent)	Maximum

F64 and above include Power BI Premium per-capacity features. Below F64, you need separate Power BI Pro licenses.

Trial: Free 60-day trial with F64 equivalent. Pay-as-you-go: Available per-second billing — only pay for what you use.

How Workloads Consume CUs

Workload	CU Consumption	Notes
Spark (notebooks)	High	Depends on cluster size, duration
Pipeline runs	Low-Medium	CUs for orchestration + activities
Copy Activity	Medium	Depends on data volume
Dataflow Gen2	Medium	Power Query processing
SQL Warehouse queries	Medium	Depends on query complexity
SQL Lakehouse endpoint	Low-Medium	Read-only queries
Power BI Direct Lake	Low	Reads Delta files (very efficient)
Power BI Import refresh	Medium	Data load into VertiPaq
KQL queries	Low-Medium	Depends on data volume scanned
Mirroring	Free compute	Only storage costs
OneLake storage	Per GB/month	~$0.023/GB/month

Throttling: What Happens When Capacity Is Exceeded

Scenario: F16 capacity (16 CUs/second)
  8:00 AM: Notebook uses 10 CUs → 6 CUs remaining → OK ✅
  8:01 AM: Pipeline uses 8 CUs → total 18 CUs → EXCEEDS 16 CU limit

What happens:
  Interactive jobs (SQL queries, report views): throttled first (slower)
  Background jobs (pipelines, refreshes): delayed or queued

Throttling levels:
  10-minute window exceeded → interactive throttling (queries slow down)
  60-minute window exceeded → background throttling (pipelines delayed)
  24-hour window exceeded → severe throttling (rejections possible)

Smoothing: How Fabric Spreads the Load

Fabric does NOT bill per-second peak usage. It uses smoothing — averaging consumption over time windows:

Without smoothing:
  8:00 AM: 100 CUs consumed (spike!) → immediate throttling on F64

With smoothing:
  Fabric averages over 5-minute windows:
  8:00-8:05 AM: Peak was 100 CUs, but average is 40 CUs → within F64 limit → no throttling

  Allows short BURSTS above capacity without penalty.
  Only sustained over-usage triggers throttling.

The rule: Short spikes (a heavy notebook for 2 minutes) are absorbed. Sustained overload (5+ pipelines running for 30 minutes) triggers throttling.

Monitoring Capacity Usage

Microsoft Fabric Capacity Metrics App

1. Open the Fabric Admin Portal
2. Install the Microsoft Fabric Capacity Metrics app from AppSource
3. Connect to your capacity
4. Dashboard shows:
5. CU utilization over time (line chart)
6. Throttling events (when and how severe)
7. Top consumers (which workloads use the most CUs)
8. Overages by workspace and item

Key Metrics to Watch

Metric	Healthy	Warning	Critical
CU utilization (avg)	< 60%	60-80%	> 80%
Throttling events/day	0	1-5	> 5
Background job delays	0 min	< 15 min	> 30 min

Pause and Resume Capacity

You can pause your capacity to stop ALL billing (except OneLake storage):

Pause:
  → All compute stops (no notebooks, pipelines, queries)
  → Data in OneLake persists (storage still billed)
  → Useful for: dev/test environments during nights/weekends

Resume:
  → Capacity starts within 1-2 minutes
  → All items available again

Automate with Azure: Use Azure Automation or Logic Apps to pause at 8 PM and resume at 7 AM on weekdays — save ~50% on dev capacity.

Cost Optimization Strategies

1. Right-Size Your Capacity

Observation: Average CU usage is 15% on F64
  → Downgrade to F16 (saves ~$6,000/month)

Observation: Frequent throttling on F16
  → Upgrade to F32 or optimize workloads first

2. Optimize Notebook and Spark Usage

# ❌ WASTEFUL: Large cluster for small data
# Session with 8 executors processing 10,000 rows

# ✅ OPTIMIZED: Match cluster to data size
spark.conf.set("spark.sql.shuffle.partitions", "10")  # Not 200 for small data
# Use starter pools for quick ad-hoc queries (lower CU footprint)

3. Optimize Pipeline Scheduling

❌ WASTEFUL: 10 pipelines all scheduled at 6:00 AM (massive CU spike)
✅ OPTIMIZED: Stagger pipelines:
  6:00 AM: Pipeline 1 + 2
  6:15 AM: Pipeline 3 + 4
  6:30 AM: Pipeline 5 + 6
  Spreads the load, avoids throttling

4. Optimize Delta Tables

-- Run OPTIMIZE weekly (fewer files = faster reads = less CU)
OPTIMIZE gold.fact_sales;

-- V-Order (automatically applied in Fabric, ensures optimal read pattern)
-- Result: Direct Lake and SQL queries use significantly less CU

5. Pause Dev/Test Capacities

Production capacity: F32, always on
Dev capacity: F4, paused nights and weekends
  → Saves ~65% on dev capacity (~$340/month saved)

F-SKU Sizing Guide

Team Size	Workload	Recommended SKU	Monthly Cost
1-3 engineers, learning	Light dev/test	F2	~$262
3-5 engineers, dev	Medium development	F4	~$524
5-10 engineers, small prod	Production workloads	F8-F16	~$1,048-$2,096
10-20 engineers, enterprise	Heavy production + Power BI	F32-F64	~$4,192-$8,384
20+ engineers, large enterprise	Multi-team, heavy analytics	F128+	~$16,768+

Common Mistakes

1. Over-provisioning capacity — running F64 when F16 is sufficient wastes $6,000/month. Monitor actual usage first, then right-size.

2. Not monitoring throttling — throttling silently delays pipelines. If your 6 AM ETL is supposed to finish by 7 AM but throttling pushes it to 8 AM, dashboards show stale data. Monitor proactively.

3. Scheduling all pipelines at the same time — creates massive CU spikes. Stagger by 10-15 minutes.

4. Not pausing dev/test capacities — paying for 24/7 capacity that is used 8 hours/day wastes 67% of the cost.

5. Ignoring Spark session cleanup — orphaned Spark sessions consume CUs. Set idle timeouts and close sessions after notebooks complete.

Interview Questions

Q: How does billing work in Microsoft Fabric? A: Fabric uses Capacity Units (CUs) as a universal compute currency. You purchase a capacity (F2 to F512) with a fixed number of CUs per second. All workloads (notebooks, pipelines, queries, Power BI) consume CUs from this shared pool. Smoothing averages consumption over time windows, allowing short bursts. Sustained overuse triggers throttling. Storage (OneLake) is billed separately per GB/month.

Q: What is throttling and how do you prevent it? A: Throttling occurs when CU consumption exceeds capacity. Interactive queries slow down first, then background jobs are delayed. Prevention: right-size capacity based on actual usage, stagger pipeline schedules, optimize Spark configurations, run OPTIMIZE on Delta tables, and pause unused dev/test capacities.

Wrapping Up

Fabric capacity management is about balance — enough CUs for your workloads without overspending. Monitor usage with the Capacity Metrics app, right-size your SKU, stagger heavy workloads, pause dev environments, and optimize Spark and Delta tables. The goal is consistent CU utilization around 50-70% — enough headroom for spikes without wasting money.

Related posts: – Fabric Foundations – Fabric Notebooks – Delta Lake Optimization

---

Naveen Vuppula is a Senior Data Engineering Consultant and app developer based in Ontario, Canada. He writes about Python, SQL, AWS, Azure, and everything data engineering at DriveDataScience.com.