Microsoft Fabric Capacity Planning Guide
Size your Microsoft Fabric capacity correctly with this comprehensive planning guide covering SKUs, workloads, and cost optimization.
Proper capacity planning for Microsoft Fabric prevents performance bottlenecks, budget overruns, and user frustration. This guide walks you through sizing methodology, SKU selection, and ongoing optimization strategies. Our Microsoft Fabric consulting team specializes in enterprise capacity planning.
Understanding Fabric Capacity Units (CUs)
Microsoft Fabric uses Capacity Units (CUs) as its compute measurement. Unlike Power BI Premium which used v-cores, Fabric CUs provide a unified compute measurement across all workloads including:
- Power BI reports and semantic models
- Data Engineering (Spark notebooks and jobs)
- Data Warehouse queries
- Real-Time Intelligence streaming
- Data Factory pipelines
Each workload consumes CUs based on the compute intensity of operations. Understanding consumption patterns is critical for right-sizing.
Capacity SKUs Overview
Development and Test - F2 (2 CUs): Individual developer testing, proof-of-concept - F4 (4 CUs): Small team development, light workloads
Departmental - F8 (8 CUs): Single department, moderate report usage - F16 (16 CUs): Multi-team department, heavier analytics
Enterprise - F32 (32 CUs): Multiple departments, significant data engineering - F64 (64 CUs): Large organization, heavy concurrent usage - F128+ (128+ CUs): Enterprise-wide, mission-critical workloads
Pay-As-You-Go vs Reserved Reserved capacity (1-year or 3-year commitment) offers 20-40% savings over pay-as-you-go pricing. Consider reserved capacity once usage patterns stabilize.
Sizing Methodology
Step 1: Inventory Current Workloads
Document all analytics workloads that will run on Fabric:
- Number of Power BI reports and datasets
- Average concurrent users by time of day
- Data volumes in each semantic model
- Existing Spark or data engineering jobs
- Scheduled refresh frequencies
- Real-time streaming requirements
Step 2: Measure Baseline Usage
If migrating from existing Power BI Premium: - Export capacity metrics from the Premium Capacity Metrics app - Identify peak usage hours and days - Note any throttling or performance complaints - Document memory and CPU utilization patterns
For new implementations: - Estimate based on similar organizations - Start with pilot workloads to establish baselines - Plan for phased rollout with capacity adjustments
Step 3: Calculate Compute Requirements
Map workloads to CU consumption estimates:
| Workload Type | Typical CU Consumption | |---------------|----------------------| | Power BI report view | 0.5-2 CU per query | | Semantic model refresh | 1-10 CU depending on size | | Spark notebook execution | 2-8 CU per job | | SQL warehouse query | 1-5 CU per query | | Dataflow refresh | 1-4 CU per entity |
Calculate total daily CU consumption, then size capacity to handle peak periods without throttling.
Step 4: Add Growth Buffer
Always include capacity headroom: - 20% buffer for organic growth - Additional capacity for new projects - Peak season considerations (month-end, quarter-end) - Buffer for unexpected spikes
Step 5: Validate with Pilot
Before full deployment: - Run representative workloads on chosen capacity - Monitor actual CU consumption vs estimates - Adjust sizing based on real measurements - Test failure scenarios and recovery
Workload-Specific Considerations
Power BI Semantic Models
Model size significantly impacts capacity needs. Consider: - Dataset memory limits by SKU (F2 supports up to 3GB models) - Large models (>10GB) require F64 or higher - Direct Lake mode reduces memory requirements - Aggregations and composite models help optimize
Data Engineering
Spark workloads can consume significant capacity: - Spark pool sizing affects job parallelism - Configure auto-scale limits appropriately - Schedule heavy jobs during off-peak hours - Monitor Spark executor utilization
Data Warehouse
Warehouse queries scale with data volume and complexity: - Monitor query patterns and durations - Implement caching strategies - Use materialized views for common patterns - Partition large tables appropriately
Cost Optimization Strategies
Right-Size Continuously Fabric capacity can be scaled up or down through the Azure portal. Review utilization monthly and adjust: - Scale down if consistently under 50% utilization - Scale up if experiencing throttling - Consider separate dev/test and production capacities
Pause Non-Production Development and test capacities can be paused during non-business hours: - Configure automated pause/resume schedules - Potential 60-70% cost savings on dev/test - Use Azure Automation or Logic Apps for scheduling
Optimize Refresh Schedules Stagger refresh schedules to avoid peak spikes: - Spread refreshes across the day - Use incremental refresh for large datasets - Schedule heavy jobs during low-usage periods
Monitor and Eliminate Waste Regularly audit for unused resources: - Reports with no viewers in 90+ days - Semantic models not connected to any report - Failed or stuck pipelines consuming resources - Overly frequent refreshes on static data
Monitoring Your Capacity
Fabric Capacity Metrics App Microsoft provides a free monitoring app that shows: - CU consumption by workload type - Peak usage times - Throttling incidents - Trend analysis over time
Key Metrics to Watch - Peak CU utilization percentage - Throttling events count - Interactive vs background workload ratio - Memory consumption by workspace
Setting Up Alerts Configure alerts for: - Utilization exceeding 80% for extended periods - Throttling events - Failed refresh operations - Unusual consumption spikes
Capacity Planning Checklist
Before deployment: - [ ] Document all workload requirements - [ ] Calculate baseline CU needs - [ ] Select appropriate SKU with growth buffer - [ ] Configure monitoring and alerts - [ ] Plan pause/resume schedules for non-prod - [ ] Document scaling procedures
Ongoing operations: - [ ] Review metrics monthly - [ ] Adjust capacity as needed - [ ] Audit for unused resources quarterly - [ ] Revalidate sizing annually
Common Sizing Mistakes
Undersizing - Leads to throttling and poor user experience - Users lose confidence in the platform - Emergency scaling is costly and disruptive
Oversizing - Wastes budget on unused capacity - Makes cost justification difficult - Could fund other data initiatives instead
Ignoring Peak Patterns - Sizing for average instead of peak - Month-end reporting spikes - Time zone differences in global organizations
Need help sizing your Fabric capacity? Contact us for a detailed capacity assessment.
Frequently Asked Questions
Can I change Fabric capacity size after deployment?
Yes, Fabric capacity can be scaled up or down through the Azure portal at any time. Changes take effect within minutes. You can also configure automated scaling based on schedules or utilization thresholds.
What happens when capacity is exhausted?
When capacity is fully utilized, Fabric implements throttling. Interactive workloads (report views) are prioritized over background workloads (refreshes). Users may experience slower report performance, and scheduled refreshes may be delayed.
Should I use one capacity or multiple?
Consider separate capacities for: dev/test vs production (different SLAs), different business units (cost allocation), and different regions (data residency). Multiple capacities add management complexity but improve isolation and cost tracking.