Our Microsoft Fabric Proof of Concept Playbook

Navy Solv Systems title card reading 'Pilot First, Reserve Later' with a checklist motif.

In Short: We Now Pilot First and Reserve Later

Until this week, almost every Microsoft Fabric proof of concept we ran ended in the same awkward place: a working pilot, a client keen to keep it, and a one-year reservation to sign before anyone really knew what the workload consumed. Microsoft's announcements at FabCon Europe 2026 change that. On-demand billing and a zero-provisioned F0 SKU are coming soon, with spend limits over a rolling 24-hour window, and capacity overage is generally available now.

So we have rewritten our playbook. We run the proof of concept on pay-as-you-go today, and on on-demand billing once the preview lands. We set the spend guardrails before a single pipeline runs. We read the capacity metrics honestly. Only then do we decide what to reserve. Here is how it works step by step, and what is available today versus what is still coming soon.

Why Reserving on Day One Never Sat Right With Me

A typical conversation with a mid-sized team goes like this. They have done the reading, they know a 1-year reservation is roughly 41% cheaper than pay-as-you-go, and they want the saving from the start. It is a fair instinct. It is also the wrong order.

A reservation cannot be paused, and it commits you to a size for a year. At the start of a pilot you do not know your refresh pattern, your concurrency or how efficient the first build is. Our capacity sizing guide has always said it plainly: reserve in month two or three, not week one. What has changed is that the flexible options are getting much better, so there is even less reason to commit early. My view is that a reservation should be the reward for a successful pilot, not the entry fee.

What Is Available Today and What Is Coming Soon

Before the steps, the status words, because this is where people get caught out. The full detail is in our F0 and on-demand billing explainer and the wider FabCon Europe 2026 recap.

Available today: pay-as-you-go F SKUs from F2, billed hourly and pausable; reserved F SKUs; capacity overage (generally available); On-demand billing for Apache Spark (generally available, the renamed Autoscale Billing for Spark); Capacity Metrics app enhancements such as heatmaps and top item contributors (generally available)
Coming soon, preview in the coming weeks: on-demand billing across Fabric, and F0 with on-demand billing on by default
Coming soon: on-demand billing for Data Warehouse
Generally available soon: workspace-level surge protection
Preview: Capacity Insights and Actions in Monitor Hub

Microsoft says availability and timelines are subject to change, and it has not published F0 pricing or the on-demand multiplier. We plan around that rather than pretend otherwise.

Step 1: Pick One Real Workload and Write Down the Exit Criteria

The pilot is one genuine workload end to end: a real source, landed and modelled, with a report or app someone actually wants. Not a feature tour. We agree up front what success means, what the business would pay to keep it, and the spend ceiling for the pilot itself. If you are coming off a trial, the same principle applies - what is and is not free in Fabric covers why a trial spent exploring tells you very little.

Step 2: Choose Where It Runs

Today: a small pay-as-you-go F SKU, paused outside working hours. That is the flexible option available right now, and a pausable capacity is the cheapest way to learn.

When the preview opens: F0 becomes the natural home for evaluation and development, since Microsoft positions it for exactly that - evaluation, development, early production and workloads whose needs are not yet predictable. On an F2 or larger capacity, we will also move a bursty billing category to on-demand rather than sizing the whole capacity for it. I would not put a hard production deadline on a preview feature, though. If a date cannot move, the pilot runs on pay-as-you-go.

Step 3: Set the Guardrails Before Anything Runs

This is the step I care about most, because "pay for what you use" also means "pay for what you forgot to switch off".

On-demand spend limits. Set per billing category in CU-hours over a rolling 24-hour window. When the limit is reached, new operations are paused, in-flight operations continue to completion, and billing resumes once the window resets. We set the limit first and loosen it deliberately, never the other way round.
Capacity overage. Billed at three times the pay-as-you-go rate and not eligible for reservation discounts. Its threshold is "a spending threshold, not a hard spending cap", and Microsoft's documentation is inconsistent on whether it is on by default, so we check it on every pilot capacity. More in capacity overage explained.
A pause schedule on any pay-as-you-go capacity, and once workspace-level surge protection is generally available, a consumption limit on the experimental workspaces.

The client signs off these numbers, not just us. Spend limits are a business decision dressed up as a setting.

Step 4: Run Representative Load, Then Measure

Two to four weeks of real schedules and real users, including month-end if that is your peak. A fortnight that misses your busiest week tells you nothing useful.

Then the Capacity Metrics app, read properly: utilisation over time, consumption by item, interactive versus background, and any throttling. On-demand usage gets its own On-demand compute tab per billing category, and it is measured without smoothing, so it reads differently from shared capacity usage. We fix the obvious inefficiency - the full refresh that should be incremental, the forgotten scheduled notebook - before treating any number as a sizing answer.

Step 5: Decide Reserved, Pay-As-You-Go or a Mix

This is where the pilot earns its keep. Our decision rules:

Reserve the baseline that runs steadily all day. On-demand is priced off the pay-as-you-go rate, and a reservation is roughly 41% cheaper than pay-as-you-go, so sustained load is likely to stay cheapest reserved.
Stay pay-as-you-go for development and anything that can be paused.
Move bursty categories to on-demand behind a spend limit, once the preview is live and the rate is published.
Fix rather than buy if one item dominates consumption.

I want to be honest about the gap. Until Microsoft publishes the on-demand multiplier and F0 pricing, the mix is a judgement, not a calculation. What the pilot gives you is the data to make that calculation in an afternoon when the rates do arrive. Our piece on how we size Fabric now that F0 exists goes deeper on the sizing side, and for smaller organisations, why pay-per-use changes the "too expensive" conversation covers when Power BI Pro alone is still the right call.

Where Solv. Systems Comes In

This is now the default shape of every Fabric proof of concept we run. Our Microsoft Fabric consultants pick the workload with you, set the guardrails before anything runs, build it properly, and hand you a sizing recommendation backed by your own capacity metrics. Sometimes that recommendation is to reserve less than you expected. That is a good outcome, and we would rather say so.

Sources and Further Reading

Frequently asked

In our view, no. A reservation is a one-year commitment and cannot be paused, and at the start of a pilot you do not yet know your consumption pattern. We run the proof of concept on a pay-as-you-go F SKU today, paused outside working hours, and reserve only once the capacity metrics show steady load.

Not yet. Microsoft lists F0 and on-demand billing across Fabric as coming soon, in preview in the coming weeks, and says availability and timelines are subject to change. The part already generally available is On-demand billing for Apache Spark, the renamed Autoscale Billing for Spark. Until the preview opens, pay-as-you-go is the flexible option.

Administrators set a limit in CU-hours over a rolling 24-hour window for each on-demand billing category. When the limit is reached, new operations are paused, in-flight operations continue to completion, and billing resumes automatically once the window resets. Usage per category shows in a new On-demand compute tab in the Capacity Metrics app.

The Capacity Metrics app: utilisation over time, which items consume the most, the split between interactive and background work, and any throttling. Run two to four weeks of representative load, including your busiest period such as month-end, and fix obvious inefficiency before reading the result as a sizing answer.

Nobody can say yet. Microsoft prices on-demand as a multiplier of the pay-as-you-go rate, which can vary by billing category, and has not published the multiplier or any F0 price. A 1-year reservation is roughly 41% cheaper than pay-as-you-go, so steady all-day load is likely to stay cheapest reserved, but that remains a judgement until rates are published.

No. Capacity overage is generally available and keeps a capacity out of throttling by billing excess usage at three times the pay-as-you-go rate, with no reservation discount. Its rolling 24-hour threshold is a spending threshold, not a hard spending cap, and Microsoft's documentation is inconsistent on whether it is on by default, so check it on every pilot capacity.