The bottom line
A Microsoft Fabric capacity is one pool of compute (measured in Capacity Units) that powers every Fabric workload, bought as an F-SKU from F2 upward. Size it on five levers — users, data volume, workload mix, refresh frequency and peak concurrency — not on price alone. Smaller organisations often start on F4–F8, mid-market on F16–F32, enterprises with AI and global reporting on F64 and up. The tables here are starting points; the Fabric Capacity Metrics App on your real workload is the only sizing that counts, and F-SKUs scale up, down or pause so it is a decision you revisit.
In This Article
Introduction
Choosing the right Microsoft Fabric capacity SKU is one of the first real decisions in a Fabric rollout, and one of the easiest to get wrong in both directions. Size it too small and reports crawl, notebooks fail and refreshes run long. Size it too large and the cloud bill climbs without a matching return.
Whether you are a startup with a handful of Power BI users or a global enterprise moving petabytes, the aim is the same: enough capacity to perform, not so much that you are paying for idle compute. This guide explains how Fabric capacity works, sets out the SKUs, and gives practical starting points by company size — with the honest caveat that the only sizing that counts is the one your own workload proves.
What a Microsoft Fabric capacity actually is
A Microsoft Fabric capacity is the single pool of compute that powers every Fabric workload, rather than a separate bill per service. One capacity runs all of it:
- Power BI
- Data Factory
- Lakehouse
- Data Warehouse
- Data Engineering
- Data Science
- Real-Time Intelligence
- OneLake
- Copilot for Fabric
- SQL analytics endpoint
Capacity is measured in Capacity Units (CU). The more CU you buy, the more your organisation can do at once — run notebooks in parallel, refresh Power BI models faster, execute heavier SQL, process larger pipelines, support more users, and switch on AI and Copilot features. The F-SKUs are the pay-as-you-go Azure form of that capacity, and they scale up, down or pause — so sizing is a decision you revisit, not one you are locked into.
The Fabric capacity SKUs
Fabric capacities come in a ladder of sizes. Each step up adds compute, memory, concurrency and headroom for heavier workloads.
| SKU | Capacity Units (CU) | Typically suits |
|---|---|---|
| F2 | 2 CU | Development, proof of concept (from ~USD 262/month) |
| F4 | 4 CU | Small teams |
| F8 | 8 CU | Small businesses |
| F16 | 16 CU | Growing organisations |
| F32 | 32 CU | Mid-sized companies |
| F64 | 64 CU | Large enterprises |
| F128 | 128 CU | Enterprise-scale analytics |
| F256+ | 256+ CU | Global organisations |
The entry point, an F2, starts at around USD 262/month and is enough to prove the platform. Everything above it is a question of how many people, how much data, and how hard you push it.
Sizing by number of users
User count is the first lever, but read it together with what those users actually do. These are market-typical starting points, not guarantees:
| Users | Typical workloads | Starting SKU |
|---|---|---|
| 10–50 | Power BI reports, scheduled refreshes, a small lakehouse, light Data Factory pipelines | F4–F8 |
| 50–300 | Multiple Power BI workspaces, pipelines, lakehouse, SQL endpoint, incremental refresh | F16–F32 |
| 300–2,000 | Enterprise reporting, large semantic models, several data-engineering teams, a warehouse, real-time analytics | F64–F128 |
| 2,000+ | Global reporting, multi-region analytics, heavy notebooks, AI and Copilot, large-scale orchestration | F256+ |
Treat the band as a floor. A hundred users reading one governed model behave very differently from a hundred each building ad-hoc reports.
The SKU is a floor, not a fix. A bloated semantic model will throttle an F64; a governed one flies on an F16. Size to the workload — then make the workload lean.
Sizing by data volume and workload
Two more levers move the number as much as users do: how much data you hold, and what you do with it.
Data volume — remember that a compressed Power BI model can look far smaller than the raw data sitting in OneLake:
| Data volume | Starting SKU |
|---|---|
| Under 100 GB | F2–F4 |
| 100 GB – 500 GB | F8 |
| 500 GB – 2 TB | F16 |
| 2 TB – 10 TB | F32 |
| 10 TB – 50 TB | F64 |
| 50 TB+ | F128+ |
Workload — a reporting-only estate and a heavy data-engineering estate of the same size need very different capacities:
| Primary use | Starting SKU |
|---|---|
| Reporting only — Power BI, semantic models, dashboards | F4–F8 |
| Reporting + ETL — Data Factory, lakehouse, pipelines, SQL endpoint | F16–F32 |
| Data engineering — Spark notebooks, Delta tables, PySpark, ML | F32–F64 |
| AI and data science — large notebooks, Copilot, AI models | F64–F256 |
Sizing by refresh frequency and concurrency
Capacity planning is not only about data size — it is about how often the data moves and how many people hit it at once.
Refresh frequency — the more often you refresh, the more compute you burn:
| Refresh frequency | Suggested SKU |
|---|---|
| Daily | F4 |
| Every 4 hours | F8 |
| Hourly | F16 |
| Every 15 minutes | F32 |
| Near real-time | F64+ |
Concurrent users — every filter, drill-down and DAX query consumes compute in the moment, so peak concurrency matters more than headcount:
| Concurrent users | Starting SKU |
|---|---|
| 10–25 | F4 |
| 25–75 | F8 |
| 75–150 | F16 |
| 150–500 | F32 |
| 500–1,500 | F64 |
| 1,500+ | F128+ |
What this looks like by company
Putting the levers together, here is where typical organisations tend to start:
| Organisation | Profile | Typical starting SKU |
|---|---|---|
| Startup (~20 staff) | Power BI, Excel, small Data Factory pipelines | F4 |
| Manufacturer (~350 staff) | IoT dashboards, production analytics, daily ETL, lakehouse, Power BI | F16–F32 |
| Retail chain (250 stores) | Inventory and sales analytics, customer analytics, hourly refresh | F32 |
| Healthcare organisation | Regulatory reporting, clinical dashboards, a warehouse, multiple departments | F64 |
| Global enterprise | Multiple countries, AI and data science, Copilot, thousands of users | F128–F256 |
Each of these is a starting point — confirmed, or corrected, once the workload runs on real data.
Common capacity-planning mistakes
Most organisations miss in one of a few predictable ways:
- Choosing the cheapest SKU without assessing the workloads
- Ignoring the next 12–24 months of growth
- Underestimating concurrent activity at peak
- Not accounting for refresh frequency
- Running several heavy workloads on a small capacity
- Never opening the Capacity Metrics App after go-live
- Assuming Power BI-only sizing applies to the full Fabric workload
The through-line: plan for the next 12–24 months, and size to the workload rather than to a price.
A capacity-planning checklist
To size well and keep the bill honest:
- Estimate user growth over the next two years, not just today
- Analyse current and projected data volumes
- Separate development, test and production where it matters
- Schedule heavy ETL for off-peak windows
- Use incremental refresh to cut compute
- Optimise semantic models, DAX and Spark notebooks
- Monitor utilisation and scale up or down on the evidence
Before you commit to a SKU, have clear answers to these:
- How many active users will access Fabric?
- Which workloads will run — Power BI, lakehouse, Data Factory, data science?
- What is the current and expected data volume?
- How often will data refresh?
- How many users will hit reports at the same time?
- Are AI, Copilot or machine-learning workloads planned?
- What growth do you expect over the next 24 months?
How we size a Fabric capacity
Sizing a Fabric capacity is a workload question, not a shopping one. It needs a read of your data architecture, your usage patterns and your growth — and, after go-live, the Microsoft Fabric Capacity Metrics App telling you the truth about CPU, memory and query performance.
Where MyData Insights helps:
- Assess current and projected workloads across Power BI, lakehouse, Data Factory and data science
- Recommend the SKU that fits — and the point at which you scale up, or pause to save cost
- Design a lakehouse and OneLake architecture that scales without a rebuild
- Optimise Power BI, Spark and Data Factory so a smaller capacity does more
- Put governance, security and cost controls in place
- Monitor utilisation and fine-tune as the estate grows
The result is a capacity sized to the evidence, not the brochure — high-performance analytics without paying for idle compute.
The right Microsoft Fabric capacity is the one your workload proves it needs — sized to users, data, refresh and concurrency, with room for the next two years and not much more. Smaller organisations often start on F4 or F8, mid-market on F16 or F32, and enterprises with AI and global reporting on F64 and up. Review utilisation as you grow, scale on the evidence, and keep the model lean. 30 minutes with Amit will turn your workload into a sized, costed capacity plan. No slides. No pitch deck. No obligation to proceed.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.