Series: Capacity Planning & Cost Management
Picking your first Fabric capacity is basically a bet on how fast your usage will grow, and most people bet wrong in one particular direction: too big, too soon.
Match size to purpose, not ambition. An F2 or F4 is plenty for a pilot or a single developer testing pipelines and reports. A departmental rollout usually lands in the F8–F32 range, while an enterprise-wide deployment needs F64 or larger. Buying big before you know your real usage just funds idle capacity. It’s tempting to buy for the org chart you’ll have in two years, but Fabric makes scaling up trivial later, so there’s little upside in paying for headroom you’re not using yet.
F64 is the licensing tipping point. Below F64, every person viewing a Power BI report needs their own Pro or PPU license, even just to look at a dashboard. At F64 and above, viewers with a free Fabric license can see content shared with them, no per-user license required. For organizations with hundreds of viewers, that one threshold can flip the economics in favor of F64. Do the math both ways before you commit — for a small pilot team, per-user Pro licenses can still be cheaper than jumping to F64 just to unlock free viewing.
F64 also happens to equal the old Premium P1. If you’re migrating from Power BI Premium, Microsoft maps capacity units directly: P1 lines up with F64, P2 with F128, and so on. Same horsepower, same guardrails, new name. If you’re already budgeting off your old Premium spend, that mapping gives you a straightforward starting point for sizing the Fabric equivalent.
Pause and resume are your cheapest cost lever. A dev, test, or pilot capacity doesn’t need to run around the clock. Pause it overnight, on weekends, or between projects, and Fabric stops billing for compute while it’s paused — just confirm nothing depends on that capacity staying live first. It costs nothing to set up beyond a few minutes of planning, and it’s the fastest way to shave a meaningful chunk off a non-production bill.
A simple first-purchase checklist works better than a spreadsheet full of guesses. Ask how many people need to view content, whether they already hold Pro licenses, and what realistic peak workload looks like. Those answers point you toward F2/F4 for exploration, a mid-tier SKU for one team, or F64 once viewer licensing dominates the math. Write the answers down before you talk to anyone about pricing — it keeps the conversation grounded in your actual needs instead of whatever SKU a vendor happens to be pushing.
Upgrade versus add a second capacity is its own decision. If one workload is simply outgrowing its SKU, scale up. But if you’re seeing “noisy neighbor” problems, where one team’s heavy job slows everyone else, a second capacity isolates that workload instead of paying for more of the same shared pool. Get this wrong and you either overpay for shared capacity nobody needed enlarged, or you keep fighting the same contention problem release after release.
Bottom line: start smaller than you think you need. Scaling a capacity up once you have real usage data is a lot easier than justifying scaling one down after buying too much too soon.
To learn more: Understand Microsoft Fabric licenses and capacity · Microsoft Fabric Capacity Planning Guide: Plan Your First Deployment · Pause and resume your Fabric capacity · Scale your capacity size · Power BI Premium to Microsoft Fabric migration FAQ (all Microsoft Learn)
This post is part of the Fabric & Power BI Essentials series — see the full series intro and article list there.
← Previous: Understanding Fabric Capacity Units (CUs) and F-SKUs | Next →: Capacity Monitoring: The Fabric Capacity Metrics App
