Fabric capacity SKUs (F2 through F2048 and beyond) are priced and marketed in a way that makes it tempting to just pick something in the middle and hope. That usually ends in either an under-provisioned capacity that throttles users during refreshes, or an over-provisioned one quietly burning budget. A better starting point is workload, not guesswork.
Inventory the workload first
Before sizing anything, list what will actually run on the capacity: how many semantic models, their size and refresh frequency, whether you're using Direct Lake or import mode, and any Spark or pipeline workloads sharing the same capacity. Capacity Units (CUs) are consumed by all of these together, not just by report viewing.
Use the metrics app, even before go-live
If you're migrating from Power BI Premium or an existing capacity, the Fabric Capacity Metrics app on your current setup tells you your actual CU consumption pattern — peak periods, refresh spikes, interactive load. That's a far better sizing input than any published benchmark, because it reflects your real usage, not a generic one.
Plan for bursting, not just steady state
Fabric capacities support bursting and smoothing, which absorb short spikes — but sustained overage throttles. Size for your typical peak (like a Monday-morning refresh-and-report-open rush), not your absolute average, and build in headroom for growth rather than resizing every quarter.
Start one tier higher than feels comfortable
In practice, the cost of slightly over-provisioning for the first few months is almost always smaller than the cost of a throttled rollout that damages user trust in the new platform. Right-size down once you have real metrics, not before.