Your Fabric capacity, policed, so the bill never surprises you

Because Fabric is sold like SaaS and charged like PaaS. Every workload in the tenant draws on the same pooled capacity, so one badly written Direct Lake query or one oversized Spark cluster can consume a month of compute over a weekend, and when the capacity is overloaded it is not the offending workload that degrades, it is the whole tenant. The people who feel it first are the ones who had nothing to do with it.

This is the part of Fabric nobody demonstrates. The pitch is a single, unified platform where storage, engineering, warehousing and reporting all sit together, and that is true. What follows the pitch is that they all sit together on one meter. The compute lever now belongs to whoever writes the next notebook, and the consequence belongs to everyone.

For an SME running Dynamics, that is a genuinely new class of risk. The old world had a fixed server, and a bad query made a bad query slow. The new world has an elastic bill and a shared ceiling, and it will let a Friday afternoon experiment run all weekend without asking anyone whether that was the plan.

• The runaway query. A Direct Lake model falls back, scans far more than it needed to, and gets scheduled to refresh hourly. It works. It is just quietly expensive, and nobody looks at it again, because the report loads.
• The accidental cluster. Someone spins up a Spark cluster to test something, sizes it generously because the dropdown offered, and does not shut it down. The compute is real from the moment it starts, whether or not anybody is using it.
• The throttle that hits everyone. Push the capacity past its ceiling and Fabric protects itself. Operations are delayed, then rejected. The finance report that had nothing to do with the offending job is the one that will not load on the last day of the month.
• The invoice nobody forecast. None of the above announces itself. It arrives later, as a number, in a month where nothing obviously changed, and by then the compute has already been consumed.

It keeps your Fabric platform fast, current and inside its budget. It covers continuous capacity monitoring with throttling headed off before users feel it, active policing of the workloads that burn capacity, spend held to a line using the F SKU cost levers, capacity sized to your real load and your real licence position, platform health kept current as Microsoft changes the stack, and access and governance upkeep. It is one continuous service, not a bag of one-off jobs.

Here is the whole of it, so there is no argument later about what the retainer covers. Two of these six cards are written for the Finance Director. Four are written for the person who gets the call when the tenant slows down.

• Capacity watched, throttling headed off. Utilisation, bursting and smoothing tracked continuously against the ceiling, with the alert arriving while there is still room to act rather than after the operations start getting rejected. Nobody should learn about a throttle from a user.
• The workloads policed. Direct Lake models, Spark jobs, notebooks, pipelines and refresh schedules reviewed against what they actually consume, not what they were expected to consume. The expensive ones get found, and the cheap fix gets made, before they become a habit.
• Spend held to a line. The Fabric cost levers exist. They are just usually left switched off. We use them: capacity paused when nothing is running, resized to the load rather than to the worst-case peak, and elastic Spark work moved onto autoscale billing. This is set out in full below.
• Sized to the load, and to the licence position. Fabric capacity sizing is not only a compute decision, it is a licensing one, and the threshold that decides it catches most buyers out. That is also set out below.
• Kept current with Microsoft. The Fabric platform moves, and so do the supported data paths out of Dynamics. We track the roadmap and absorb the re-plumbing, so the estate never quietly falls behind a deprecation or a change to how a workload is metered.
• Access and governance kept clean. Workspace roles, access reviews and OneLake permissions kept accurate as people and projects change, so a governed platform does not drift out of governance. Where the governance work goes deeper, see Fabric governance and security.

With the three levers Microsoft only ships on the F SKUs. Pause and resume, on-demand resizing and Spark autoscale billing are F SKU features and are not available on P. Those three are how a Fabric bill is held to a line: the capacity is paused when nothing is running, resized to the real load instead of the worst-case peak, and elastic Spark work is billed as it bursts rather than being carried inside a reserved peak all month. Everything else is guesswork.

This matters more than any benchmark, because it is not a benchmark. It is Microsoft's own SKU feature matrix. If your capacity cannot be paused, cannot be resized on demand and cannot autoscale its Spark billing, then there is no meaningful cost control available to you, and the only thing standing between the business and a large invoice is everybody's good behaviour.

1. Pause and resume

   A capacity that is running is a capacity that is charging, whether or not a single query is executing. Batch and overnight workloads do not need the meter on all day, so the capacity is paused when the work is done and resumed for the next window, on a schedule that tracks how the business actually works rather than how the calendar looks.

2. Resize on demand

   Capacity is not a fixed line on a bill, it is a dial. The platform runs on the size the ordinary week needs, moves up for month-end, the annual audit, the migration weekend or the big historical load, and comes straight back down afterwards. Sizing for the worst week you will ever have, and then paying for it fifty-two times, is the most common way an SME overspends on Fabric.

3. Autoscale the Spark billing

   Data engineering is bursty by nature. Autoscale billing lets the elastic Spark work be paid for as it bursts, rather than being carried inside a reserved peak that sits idle the rest of the month, which is what makes engineering workloads affordable instead of frightening.

If you are still on a P SKU, this is the part that decides your timing. P SKUs can no longer be bought, only renewed, and the Power BI Premium SKUs are being retired, so the conversion happens at your own renewal date rather than on a market-wide deadline. The practical consequence is simply that until you convert, the three levers above are not available to you. That is the honest reason to move, and it is a better one than any deadline. If the legacy pipe you built on has already been retired, as Export to Data Lake has, the timing decides itself. We can help you plan the conversion: see migration to Microsoft Fabric.

F64 is the threshold at which people can view Power BI content on a free Fabric licence. Below F64, every single viewer needs a Pro licence. That makes capacity sizing a licensing decision as much as a compute one, and it is the cost cliff most often missed: an under-sized capacity can cost more in per-viewer licences than it ever saved in compute, while an over-sized one burns compute nobody uses.

Most sizing conversations only ask one question, which is how much work the platform has to do. That is half the question. The other half is how many people are going to look at what it produces, because that is what decides whether they all need a licence each.

It is a genuinely awkward shape. The right answer is not "buy the biggest capacity", and it is not "buy the smallest one you can survive on" either. It depends on the size of your consumer population, on how that population is going to grow, on which workloads are elastic and which are constant, and on whether the peaks are predictable enough to be handled by resizing rather than paid for permanently. Get it right and the platform is cheaper and faster at the same time. Get it wrong in either direction and you pay for that every month, quietly.

This is exactly the kind of decision that is easy to take once, badly, and then never revisit. It is one of the first things we baseline when a platform comes under management, and one of the things we keep revisiting as the business changes.

Your platform comes under management through a readiness review or a build handover, then runs on a continuous rhythm: baselined, instrumented, policed, optimised to cost and reviewed with you on a regular cadence. The service comes in tiers matched to how much coverage your platform genuinely needs, and the shape of it is agreed with you before you commit.

This is a worked service with a rhythm to it, not a monitoring dashboard you are given a login to and never open. Here is how a platform comes under management, and what the ongoing cadence looks like.

1. Baseline the capacity

   We find out what the platform is actually doing: which workloads consume what, where the capacity sits against its ceiling, whether the size and the licence position are right, and what the spend looks like once it is finally attributed to something. Most of this is not visible to the people paying for it.

2. Instrument and police

   Monitoring goes on the capacity, the workloads and the spend, with the thresholds set where they still leave room to act. The expensive workloads get corrected, the ones that should not be running get switched off, and the tenant stops being one bad notebook away from a slow month-end.

3. Optimise to cost

   The levers get used, continuously and deliberately: paused when idle, resized to the load, Spark billed as it bursts. Alongside that, the platform is kept current as Microsoft changes the stack, so the estate never falls behind a deprecation or a change to how a workload is metered.

4. Review with you

   A regular cadence: what the platform cost, what it did, what got throttled and why, what we fixed, and what we recommend next. The service is meant to be visibly earning its place, and this is where you check that it is.

The service comes in a tiered shape, so you fund the level of coverage your platform actually needs.

• Good. The reliable core: capacity monitoring, throttle prevention, and the essential cost and platform upkeep that keeps Fabric trustworthy and predictable.
• Better. The core plus a fuller optimisation and workload-policing cadence, and more included expert time, for a busier platform with more builders on it.
• Best. The fullest coverage: the widest monitoring scope, the most frequent optimisation, and the most included expert time, for a platform the business genuinely runs on.

Each tier is tailored to your platform and defined with you before you commit.

It is the top rung, and the one that lasts. You diagnose first, then you migrate or build, then you run it, with governance running alongside the whole way. You never have to commit further up the ladder than the value you have already seen, and an estate somebody else built is a perfectly normal place to start.

1. Diagnose first.

   If you do not yet know what your capacity is doing, or whether Fabric is even the right platform decision for you, start with a Fabric readiness and strategy assessment. It is the cheapest way to find out where you actually stand.

2. Then migrate, or build.

   If you are still on a legacy path or an old capacity, migration to Microsoft Fabric is the door. If the platform needs designing and building properly, that is Fabric architecture and implementation. Both hand over documented, straight into managed, with no gap where the platform starts to decay.

3. Then run it.

   This page. The platform run continuously, the capacity policed, the spend held to a line, so it stays fast and stays affordable without anybody in your team carrying it.

4. Govern it throughout.

   Governance is not really a rung, it runs alongside all of them. Fabric governance and security covers the OneLake security model, the access design and the compliance position.

For the full Dynamics programme this service sits inside, see Microsoft Fabric for Dynamics 365.

This service runs the platform, which is the layer underneath everything else. The reconciled model layer that sits on the platform is a separate practice: see data warehouse. The reporting on top of that model is a separate practice again: see Power BI. We keep the platform fast and the capacity affordable. Those two keep the numbers reconciled and the reports trustworthy on top of it.