How We Size Microsoft Fabric Now That F0 Exists

Navy Solv Systems title card reading 'How We Size Fabric Now That F0 Exists' with a stacked capacity blocks motif.

In Short: Microsoft Fabric Capacity Sizing Now Starts With Workload Shape

For as long as we have been doing Microsoft Fabric capacity sizing at Solv. Systems, the first real question in the room has been some version of "F2 or F64?". Pick a SKU, then make the workloads fit it.

FabCon Europe 2026 changed that. Microsoft announced a zero-provisioned F0 SKU with no upfront compute-capacity charge, and on-demand billing across Fabric, both coming soon in preview "in the coming weeks". So we are changing how we size. We now start from the shape of each workload, keep reservations for load we have actually seen and measured, and are honest that some of the maths cannot be done yet, because Microsoft has not published the prices.

The Old Conversation: "F2 or F64?"

A typical first sizing conversation used to go like this. The team has a few data sources, a handful of reports, maybe a data engineer starting on a lakehouse. Someone has read that F64 means report viewers no longer need their own Power BI Pro licence. Someone else has seen the F64 price and gone quiet. And we spend the next hour debating a single number that has to cover development, refreshes, month-end and the CEO's dashboard all at once.

That was never really a sizing exercise. It was a guess about the peak, wrapped in a licensing argument.

To be fair to the old model, it was the only one on offer. Every workload had to run inside a capacity you had paid for in advance, so you either sized for the peak and paid for idle headroom, or sized for the average and lived with throttling. Our Microsoft Fabric capacity sizing guide was built to make that guess as good as possible: run real workloads on pay-as-you-go for two to four weeks, read the metrics, fix the inefficiency, then reserve.

That method still holds. What has changed is the question at the end of it.

What Actually Changed, and What Is Still Coming

It is worth being precise, because a lot of people I speak to think they can switch F0 on today. They can't. Here is the status as Microsoft announced it on 29 September 2026, covered in full in our explainer on Fabric F0 and on-demand billing:

F0 (Fabric zero-provisioned) - coming soon, in preview in the coming weeks, with on-demand billing on by default
On-demand billing across Fabric - coming soon, in preview in the coming weeks; on F2 or larger you will be able to move individual billing categories outside the shared capacity
On-demand billing for Data Warehouse - coming soon
On-demand billing for Apache Spark - generally available, the renamed Autoscale Billing for Spark, pricing unchanged
Capacity overage - generally available now, billed at three times the pay-as-you-go rate
Workspace-level surge protection - generally available soon

Microsoft's own feature summary adds: "Availability and timelines are subject to change." I take that seriously, and so should anyone planning a go-live around it.

The line from Microsoft that matters most for sizing is that on-demand billing helps "keep variable workloads from competing with predictable workloads for shared capacity". That is the whole shift in one sentence. For the wider event, see our FabCon Europe 2026 recap.

How We Size Microsoft Fabric Now: Shape First, SKU Second

These days we don't open with a SKU. We open with a list of workloads, and for each one we ask what its demand looks like over a day, a week and a month. Almost everything falls into one of three shapes.

Steady. Scheduled refreshes, core reporting, daily pipelines. It runs at a similar level most of the day, every day. This is what a provisioned capacity is good at, and what a reservation rewards.
Bursty. Month-end close, a seasonal promotion, a quarterly forecast, a big backfill. Quiet most of the time, heavy for a few days. Microsoft's own example is moving the Data Warehouse category to on-demand billing during a seasonal promotion, then back to the shared capacity once demand settles.
Unknown. A new proof of concept, a first lakehouse, a data science experiment. There is no history, so any SKU we pick is a guess. This is the shape F0 is designed for.

Once each workload has a shape, the conversation becomes a design rather than a debate. The steady workloads set the size of the baseline. The bursty ones become candidates for on-demand billing behind a spend limit, or for overage as a safety net. The unknown ones get measured first, without a commitment.

One thing doesn't change: inefficiency is still the most expensive shape of all. A badly written dataflow is just as wasteful on on-demand billing as on a reserved F16, and arguably more visible on the invoice. So we still fix it before sizing anything. Our explainer on how Fabric measures usage covers why, including smoothing, which on-demand consumption does not get.

Reservations Are for Proven Steady Load

My view hasn't softened on this: a reservation is still the cheapest way to run Fabric for work that runs all day. Microsoft did not change pay-as-you-go or reserved prices, a reservation is roughly 41% cheaper than pay-as-you-go for the same SKU, and on-demand is priced as a multiplier of the pay-as-you-go rate. For genuinely steady load, the reservation is very likely to stay the winner.

What has changed is our bar for what counts as steady. We now only reserve load we have seen in the Capacity Metrics app over a representative period, month-end included. Not load we expect to see once adoption picks up. Not headroom "just in case". If the case for a bigger reservation rests on a peak that happens three days a month, that peak is a candidate for on-demand billing once it reaches preview, not a reason to commit to a larger SKU for a year.

Two exceptions still override the shape logic. If you need F64 or above so viewers don't each need a Pro licence, that is a licensing decision, and our F64 guide works through it. And if a deadline can't move with a preview, plan on what is generally available today.

We step through the measure-then-decide sequence in our new pilot first, reserve later playbook.

What We Can't Size Yet

This is the bit I want to be straight about. Microsoft has not published F0 pricing, and it has not published the on-demand multiplier. Without them, nobody can tell you where on-demand stops being cheaper than a reservation for your workload. Anyone who gives you a precise break-even today is guessing.

There are a few other gaps. The announcements do not list every billing category that will support on-demand billing at launch. They say nothing about Power BI licensing on F0, so until Microsoft documents otherwise, we assume F0 does not change the need for Power BI Pro below F64. And the node-based billing model mentioned for Data Warehouse has no published pricing either.

We also treat the controls as part of the design. On-demand spend limits work in CU-hours over a rolling 24-hour window: new operations pause when the limit is reached and resume when the window resets. Overage, by contrast, has "a spending threshold, not a hard spending cap", and Microsoft's documentation is inconsistent on whether it is on by default, so we check every capacity. Our post on capacity overage has the detail.

So for now, our sizing recommendations come in two parts: a baseline we can price today, and an on-demand line we leave blank until the numbers arrive. For smaller teams, where this matters most, I have written about why pay-per-use changes the "Fabric is too expensive" conversation.

Where Solv. Systems Comes In

What we're doing with clients this month is simple. We read the capacity metrics, label every workload steady, bursty or unknown, and recommend a reserved baseline that covers only proven load. We flag which categories to move to on-demand billing once it reaches preview, with spend limits agreed before anything runs. If you're about to renew or extend a reservation, our Microsoft Fabric consultants can run that review with you first.

Sources and Further Reading

Frequently asked

No. F0 removes the upfront compute-capacity charge, but you still pay for what you consume, and once a workload runs steadily all day a provisioned or reserved capacity is likely to be cheaper. Sizing shifts from picking a SKU up front to deciding which workloads belong on a reserved baseline and which belong on on-demand billing.

Not yet. Microsoft announced F0 and on-demand billing across Fabric at FabCon Europe 2026 on 29 September 2026 as coming soon, in preview in the coming weeks, and notes that availability and timelines are subject to change. On-demand billing for Apache Spark, the renamed Autoscale Billing for Spark, is already generally available, as is capacity overage.

It is the pattern of demand over time rather than the volume of data. A steady workload runs at a similar level most of the day, a bursty one spikes around month-end or campaigns, and an unknown one has no history yet. Each shape points to a different billing model: reserved capacity, on-demand billing behind a spend limit, or F0 and pay-as-you-go while you measure.

When you have proven, steady load from real capacity metrics, when you need F64 or above so report viewers do not each need a Power BI Pro licence, or when a fixed deadline cannot wait for a preview. A reservation is roughly 41% cheaper than pay-as-you-go for the same SKU, but it cannot be paused.

Microsoft has not published F0 pricing or the on-demand multiplier. On-demand consumption is measured in CU-hours without smoothing and priced as a multiplier of the pay-as-you-go capacity price, which can vary by billing category. Until the multiplier is published, nobody can calculate where on-demand stops being cheaper than a reservation.

Not on the strength of an announcement. Our view is to keep reservations that cover proven steady load, avoid extending ones that cover idle headroom without a review, and gather capacity metrics now so you can compare quickly once Microsoft publishes prices.