Forum Discussion
Help with Microsoft Fabric Capacity Sizing for Production Power BI Environment (F4 vs F8 vs F16)
Help with Microsoft Fabric Capacity Sizing for Production Power BI Environment (F4 vs F8 vs F16)
Hi everyone,
Our organization is planning to migrate ownership of a customer's Power BI environment to our own tenant. Since we will be responsible for purchasing and managing the Microsoft Fabric capacity, we want to ensure we choose the right SKU based on workload rather than simply guessing.
I'd appreciate feedback from Microsoft MVPs or anyone who has sized similar production environments.
Current Environment
Power BI Import Mode
Star Schema
Data Source: Snowflake
Incremental Refresh enabled
Scheduled refresh every 2 hours
Approximately 100+ report users
Typical concurrent users: ~20
20 Production reports
20 Development reports (same semantic models)
Data Model
The reports use a star schema with:
Import mode semantic models
Incremental Refresh
Aggregated fact views from Snowflake (AG2_*_SUBHOUR_V, IVR_SUBHOUR_V, etc.)
Shared dimension views (DATE_TIME_V, PERSONS_V, QUEUES_V, DIVISIONS_V, MEDIA_TYPES_V, INTERACTION_TYPES_V, etc.)
Most reports reuse the same dimension tables while querying different aggregated fact views.
Relationships are primarily one-to-many from dimensions to fact tables.
The largest fact view currently contains approximately 46.6 million rows (3 months of data).
Refresh Pattern
Currently All 11 reports refresh simultaneously every 2 hours
One more thing
our models use aggregated/subhour fact views rather than detailed transaction tables.
For example:
The reports are built on aggregated Snowflake views (AG2_*_SUBHOUR_V and IVR_SUBHOUR_V) rather than detailed interaction-level fact tables. These views are joined with shared dimension tables in a star schema.
Current Semantic Model Sizes
Report Size
| Report 1 | 148 MB |
| Report 2 | 76 MB |
| Report 3 | 38 MB |
| Report 4 | 29 MB |
| Report 5 | 23 MB |
| Report 6 | 16 MB |
| Report 7 | 13 MB |
| Report 8 | 6 MB |
| Report 9 | 2 MB |
| Report 10 | 1 MB |
| Report 11 | ~1–2 MB |
Total Production Semantic Models are approximately 350 MB.
Largest Source Tables (Current 3 Months)
View Rows
| Report 1 | 46,639,471 |
| Report 2 | 2,218,543 |
| Report 3 | 2,218,543 |
| Report 4 | 2,150,647 |
| Report 5 | 937,713 |
| Report 6 | 925,482 |
| Report 7 | 401,283 |
| Report 8 | 248,349 |
Although the semantic models are relatively small, the refresh process reads and processes tens of millions of rows from Snowflake.
Refresh Characteristics
Refresh every 2 hours
Average refresh duration: approximately 8–13 minutes
Import mode with Incremental Refresh
Snowflake is the data source
Expected Growth
The current environment contains only about 3 months of historical data.
The business plans to retain 3 years of historical data, so the source tables are expected to grow substantially over time.
Questions
Based on this workload, which Fabric capacity would you recommend as the starting point: F4, F8, or F16?
- If you were sizing this as a new production environment, what information would you consider most important, and based on the information provided, which Fabric SKU (F4, F8, F16, or higher) would you recommend?
Is F8 a reasonable starting SKU, or would you recommend sizing differently?
How much weight should be given to:
Semantic model size
Source table row count
Refresh frequency
Concurrent users
Since our semantic models are relatively small but the source tables are large, which factor should drive capacity planning?
Are there any Microsoft best practices or sizing calculators that you recommend for validating the selected Fabric SKU?
We'd like to make an evidence-based decision before purchasing Fabric capacity, so any recommendations or real-world experiences would be greatly appreciated.
Thank you!
Your bottleneck here is refresh, not model size, so size for that: 350 MB of models is nothing, but 11 models refreshing simultaneously off tens of millions of Snowflake rows every 2 hours is what will drive CU usage, so I'd start at F8 rather than F4 (F4 is tight for that concurrent refresh burst) and stagger the refreshes if you can. Scaling is instant and online, so start at F8, watch the Fabric Capacity Metrics app for overload during the refresh windows, and bump to F16 only if the data says so. One thing that's easy to miss: below F64, all 100+ report users each need a Pro license, so check whether viewer licensing rather than compute is actually the deciding cost before you settle on a SKU.
4 Replies
Looking at the numbers, I'd probably start with F8.
The model sizes themselves don't look huge, but the combination of 2-hour refreshes, multiple models refreshing at the same time, and expected growth over the next few years is what would make me cautious about going with F4.
I'd also try to stagger the refresh schedules a bit instead of having everything refresh together. That can make a noticeable difference.
F16 feels a little oversized based on the current workload unless you're expecting significant growth or planning to run other Fabric workloads on the same capacity.
If this were my environment, I'd start with F8, keep an eye on the capacity metrics for a few weeks, and then decide whether there's a real need to scale up.
Answer 1: Recommend starting with an F8 capacity.
Answer 2: Consider Source Data Growth & Ingestion Compute most important; recommend F8 (or F16 as data scales 12x over 3 years).
Answer 3: Yes, F8 is reasonable because F4 is too restrictive for large source processing.
Answer 4: Give 40% to Refresh frequency, 30% to Concurrent users, 20% to Semantic model size, and 10% to Source table row count.
Answer 5: Data Ingestion and Transformation Compute (ETL/Refresh processing) should drive capacity planning.
Answer 6: Use the official Microsoft Fabric Capacity Metrics App along with pay-as-you-go scaling to monitor actual Capacity Unit (CU) usageYour bottleneck here is refresh, not model size, so size for that: 350 MB of models is nothing, but 11 models refreshing simultaneously off tens of millions of Snowflake rows every 2 hours is what will drive CU usage, so I'd start at F8 rather than F4 (F4 is tight for that concurrent refresh burst) and stagger the refreshes if you can. Scaling is instant and online, so start at F8, watch the Fabric Capacity Metrics app for overload during the refresh windows, and bump to F16 only if the data says so. One thing that's easy to miss: below F64, all 100+ report users each need a Pro license, so check whether viewer licensing rather than compute is actually the deciding cost before you settle on a SKU.
Hi manoj_0911 ,
Thank you for reaching out to fabric community.
Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address.
Thanks!!
