Microsoft Fabric capacities range from F2 to F2048, and each tier provides a different level of compute. F64 is an important licensing threshold because eligible users with Fabric Free licences can view shared Power BI content hosted on the capacity. Smaller F SKUs can also support production workloads when the required features, licensing model, and measured workload demand are a good fit. Choosing the right size can still feel like guesswork, especially if you are new to Fabric or have never managed dedicated Power BI capacity before.
Power BI Premium per-capacity subscriptions have been retired, so organizations using P SKUs need to plan a move to Fabric F SKUs. Fabric capacity can be billed on a pay-as-you-go basis, and a one-year reservation can reduce capacity costs by up to about 40%. Pricing varies by region, so check the Azure pricing calculator for your region and agreement.
Choosing the right starting point matters, but measuring before making a long-term commitment matters even more.
Scenario #1: Have Never Used Dedicated Capacity
- Start with a pay-as-you-go F SKU that matches your expected workload. If you have little usage data, start small and scale up gradually as the metrics show sustained demand.
- Use the Microsoft Fabric Capacity Metrics app to watch average and peak utilization, workload patterns, throttling, and query rejections over a representative period.
- If utilization is stable and users are not experiencing throttling, delays, or query rejections during representative peak periods, the capacity may be a good fit.
- If the metrics show sustained overload, scale up or optimize the workloads and test again. If the capacity is consistently underused, scale down and continue monitoring.
Scenario #2: Moving from Power BI Dedicated Capacity
- Review your current capacity usage and current size.
- Use the current capacity size and actual usage patterns as a baseline, then test a comparable F SKU before switching production workloads. Moving to a similar nominal size can reduce migration risk, but it still needs to be validated because workloads, features, and consumption patterns differ.
- If your current Power BI workloads consume a large share of the capacity, leave room for the new Fabric workloads you plan to add. Test the workloads together and use the metrics to decide whether to scale up.
Scenario #3: Consolidating Multiple Workloads
- Many customers in this situation want to bring several analytics workloads together to reduce cost and complexity and make the platform easier to manage.
- This could include moving Power BI, Azure Data Factory, Azure Synapse, and SQL database workloads into Microsoft Fabric.
- For a multi-workload migration, use a pay-as-you-go capacity while testing representative Power BI, data integration, engineering, warehouse, and database workloads together. Start with the smallest practical SKU for the test, review how the workloads coexist, and scale up or down based on the Capacity Metrics app.
Across all three scenarios, the goal is not to buy the biggest capacity, but to avoid sustained overload while leaving room for growth. When demand remains above the capacity’s limits after smoothing, Fabric can delay or reject operations through throttling. People sometimes call this “Fabric Jail,” and I’ll unpack it in next week’s post.
What surprised you when choosing a Fabric capacity—or after your workloads went live? Share your experience or reach out with questions.
