Microsoft Fabric Capacity Planning - How to Size Workloads Without Overbuying

The single most expensive decision in a Fabric project is the SKU you choose at the start. Pick too small and your reports time out, your pipelines back up, and your users go back to whatever they were doing before. Pick too big and you bleed thousands of dollars a month on capacity you never touch.

We have planned Fabric capacity for Australian organisations across financial services, healthcare, manufacturing, and government. The good news is that the F-SKU model is forgiving once you understand the levers. The bad news is that Microsoft's official sizing guidance is written at such a high level it is not much use when you actually have to commit a budget.

This post is the version of the conversation we have with clients before they sign anything. Real scenarios, AUD numbers, and the questions worth answering before you pick a SKU.

The F-SKU Ladder in AUD (2026 Pricing)

Fabric capacity is sold under F-SKUs. The SKU number is the number of Capacity Units (CUs) you get. The pricing scales linearly which means the per-CU cost is the same at F2 as it is at F2048. Here is the rough pay-as-you-go pricing in Australia East as of mid-2026:

SKU	CUs	Pay-as-you-go (AUD/month)	Reserved 1-year (AUD/month)
F2	2	~$390	~$230
F4	4	~$780	~$460
F8	8	~$1,560	~$920
F16	16	~$3,120	~$1,830
F32	32	~$6,240	~$3,660
F64	64	~$12,480	~$7,320
F128	128	~$24,960	~$14,640
F256	256	~$49,920	~$29,280

Two things to notice. First, reserved capacity is roughly 41% cheaper. If you know you are keeping Fabric for at least a year, the reservation pays for itself in about seven months. Second, F64 is the threshold where Power BI Pro licences are no longer required for report consumers, which can save a lot in user licensing for big organisations.

The pay-as-you-go pricing assumes you keep the capacity running. You can pause F-SKUs and stop the meter, which makes them genuinely useful for dev and test environments that only run during business hours. A paused F4 costs nothing.

The F64 Power BI Threshold Changes the Maths

If you have more than about 30-40 Power BI report consumers, F64 starts to look cheap. Power BI Pro is around $19 AUD per user per month. At 40 users that is $760 a month in licensing alone. Add the small F-SKU you would have bought anyway and you are well over the F64 price.

We had one client who was sitting on an F16 with 90 Pro users. They were paying about $3,120 for capacity plus $1,710 for Pro licences. Moving to F64 reserved capacity at around $7,320 a month and dropping the Pro licences saved them about $2,500 a month while giving them four times the compute headroom. The Pro licensing model breaks down quickly at scale.

If you are nowhere near 30 users though, do not buy F64 for the licensing economics. The capacity itself is the dominant cost.

Sizing by Workload Profile (Not by Organisation Size)

Most sizing guides try to map organisation size to SKU. That mapping is mostly useless. A 50-person fintech with heavy real-time analytics will burn through capacity that a 5,000-person retailer with one nightly batch job will not touch. Size by workload profile, not headcount.

Here are the profiles we see most often in Australian businesses, with the SKU range that has worked in practice:

Profile 1: Reporting-Only Migration

You are moving Power BI Premium Per User or shared capacity reports onto Fabric. Maybe a few Dataflows feeding the models. No Spark, no Warehouse, no Real-Time Analytics. Refreshes happen overnight.

• Typical SKU: F4 to F16 reserved
• Monthly cost: $460 to $1,830 AUD
• Watch out for: Multiple large semantic model refreshes hitting at the same time. Stagger them.

Profile 2: Lakehouse + Power BI

You have built a medallion architecture in OneLake. Daily ingestion from a few source systems, Spark jobs to clean and shape the data, then Power BI on top via Direct Lake. This is the most common pattern we see.

• Typical SKU: F16 to F64 reserved
• Monthly cost: $1,830 to $7,320 AUD
• Watch out for: Spark jobs that auto-scale aggressively and burn CUs you did not budget for. Set executor caps explicitly.

Profile 3: Warehouse-Heavy Analytics

You are using Fabric Warehouse as the primary serving layer with SQL endpoints for tools beyond Power BI. Lots of concurrent queries from analysts, business users, and downstream applications.

• Typical SKU: F32 to F128 reserved
• Monthly cost: $3,660 to $14,640 AUD
• Watch out for: Bad queries from ad-hoc users. A single full table scan on a wide warehouse can eat hours of CU budget.

Profile 4: Real-Time + Operational Analytics

You have streaming data coming in via Eventstream and KQL databases, you are running operational dashboards that need to be fresh in minutes, and you have batch workloads running alongside.

• Typical SKU: F64 to F256 reserved
• Monthly cost: $7,320 to $29,280 AUD
• Watch out for: KQL ingestion is a constant CU consumer, unlike batch which spikes and stops. Budget for the baseline load not the average.

Profile 5: Full Platform with AI/ML Workloads

Everything in profile 4 plus Spark ML workloads, Fabric Data Agent, Copilot in Fabric usage across the business, and Data Activator triggering downstream actions.

• Typical SKU: F128 and above
• Monthly cost: $14,640+ AUD
• Watch out for: Copilot in Fabric consumption can be sneaky. It uses meaningful CUs per interaction and adoption ramps fast once users find it useful.

The Sizing Method We Actually Use

Forget the official capacity sizing tools for a minute. They assume you can predict workload behaviour before you run it, which you cannot. Here is the method we use with clients:

Step 1: Identify your peak hour. Not your average. What does Tuesday 9am look like when the morning refresh just finished and the business is opening Power BI reports? That hour is what your capacity has to survive.

Step 2: Inventory your workloads. For each one, estimate the CU draw using rough rules. A semantic model refresh: 50-500 CU-seconds depending on size. A complex Power BI page load with 12 visuals: 5-15 CU-seconds. A Spark job processing 10 million rows: 100-500 CU-seconds. A Warehouse query joining four large tables: 10-100 CU-seconds.

Step 3: Multiply by concurrency. If you have 60 users opening reports at 9am and the average page load is 8 CU-seconds, you are looking at 480 CU-seconds in that minute alone. Divide by 60 to get the sustained per-second draw: 8 CUs sustained for that minute.

Step 4: Add 30-40% headroom. Fabric smooths consumption across 5 minutes for interactive workloads and 24 hours for background, so brief spikes above your SKU are fine. Sustained overage is what causes problems.

Step 5: Pick the SKU above your calculated number. F-SKUs are cheap to change. You can scale up and down without losing data. Start one SKU above your estimate, monitor for two weeks, then adjust.

This method has been more accurate for our clients than any capacity calculator I have seen. The reason is that real workloads do not match the assumptions in the calculators. Your users will write inefficient DAX. Someone will schedule three large refreshes at the same time. A new dashboard will become popular and the load will double.

Common Sizing Mistakes We See Often

A few patterns show up again and again in Australian Fabric implementations:

Sizing for the cheapest first month. Teams pick F4 because the bill looks manageable, then spend the next quarter scaling up in panic. The cost of two emergency capacity upgrades plus the lost productivity from throttled users far exceeds the cost of starting at F16.

Ignoring background workloads. Pipeline runs and Spark jobs draw CUs continuously when they are running. If your overnight batch overruns into business hours, you are now competing with interactive queries on the same capacity. We have had clients hit throttling at 10am because a Spark job started at 4am was still running.

Forgetting about Copilot. Copilot in Fabric usage charges to your capacity. If 50 users start using it daily and each interaction costs a few CU-seconds, that is real consumption you did not budget for. The Copilot ROI is usually worth it but you have to size for it.

Buying P-SKUs instead of F-SKUs. P-SKUs (Power BI Premium capacity) still exist but they are legacy. F-SKUs include all Fabric workloads plus Power BI Premium features at a comparable price point. There is rarely a good reason to buy P-SKUs in 2026.

Buying one big SKU when two smaller ones would be better. If you have a clear separation between production and dev/test, two F8s (production always-on, dev paused outside business hours) often costs less than a single F16 with everything mixed together. The pause feature is a real saving.

The Multi-Workspace Question

If you are running Fabric across multiple business units, you have a choice: one large capacity shared across workspaces, or separate capacities per workspace/business unit.

We almost always recommend separate capacities for distinct business units. The reason is that capacity is the unit of isolation. A bad query or runaway Spark job in one workspace will affect every other workspace on the same capacity. With separate capacities, the blast radius is contained.

The downside is that you cannot pool unused CUs across capacities. If marketing has spare CUs and finance is throttling, the spare CUs cannot help. You have to accept some overall over-provisioning in exchange for fault isolation.

For a single business unit with multiple workspaces (dev, test, prod), one shared capacity is usually fine. The workloads are coordinated and the isolation problem does not really apply.

Monitoring That Actually Tells You Something

Buy the capacity, but also commit to monitoring it. The Fabric Capacity Metrics app (free, from AppSource) shows you CU consumption over time by workload and operation. Look at it weekly for the first two months.

The two metrics worth watching:

• CU consumption smoothed over 5 minutes during business hours. If this is consistently above your SKU's CU limit, you are throttling interactive workloads.
• Background throttling events. If pipeline runs are being delayed, you are over-subscribed even if it does not look like it during peak.

If you are not throttling and your average CU usage is under 50%, you are probably over-sized. Drop a SKU and save money. If you are throttling at all, you need more capacity or workload optimisation, often both.

When to Get Help

Capacity planning gets harder when:

• You have mixed workloads (Spark + Warehouse + Power BI + Real-Time) and need to balance them
• You are migrating from Synapse or another platform and the workload profile will change
• Your organisation is growing fast and you cannot use historical data to predict future load
• You have unpredictable demand from internal users running ad-hoc queries

These are the scenarios where engaging Microsoft Fabric consultants pays back fast. The cost of two weeks of consulting is usually less than one month of over-provisioned capacity, and the right architecture decisions early save a lot of remediation work later.

We help Australian organisations size Fabric correctly, build the medallion architectures that run efficiently within those capacity limits, and set up the monitoring that keeps everything right-sized over time. If you are about to commit to a Fabric SKU and want a second opinion before you sign, get in touch or read more about how we work with Microsoft data factory and Power BI projects.

The wrong SKU is expensive but reversible. The wrong architecture is expensive and slow to fix. Get both right at the start and Fabric is one of the better data platforms on the market.