How to reduce Microsoft Fabric capacity costs: 10 checks before you upsize
When a Microsoft Fabric capacity starts throttling, the usual fix is to move up a SKU. F64 becomes F128 and the bill doubles. Sometimes that's the right call. But more often the capacity is sized for a few peaks, runs at full price around the clock, and carries a few items that use far more compute than they should.
Before you approve a bigger SKU, work through these ten checks. Each one relies on documented Fabric behaviour and on data you already have in the Capacity Metrics app.
First, how Fabric actually bills you
An F capacity is an Azure resource. Microsoft bills it per second with a one-minute minimum and no commitment, and pricing varies by Azure region (Microsoft Learn: Fabric licenses). You pay for the size you provision while it's running, not for the work you run on it. A capacity left at F64 all week costs the same whether it's busy or idle.
Each SKU provides a fixed number of capacity units (CUs): F2 has 2, F64 has 64 and F256 has 256. In compute terms, F64 corresponds to Power BI Premium P1, F128 to P2 and F256 to P3. Microsoft frames this as a compute comparison, not a licensing equivalence (same source). OneLake storage and networking are billed separately from capacity.
1. Read the Capacity Metrics app before you buy anything
The Microsoft Fabric Capacity Metrics app shows CU consumption by item, operation and time. Look at three things:
- How utilisation moves over a typical week.
- How often you actually go above 100%.
- Which items account for most of the CU seconds.
In most tenants a short list of items accounts for most of the consumption. Fixing them is far cheaper than doubling the capacity.
2. Understand smoothing before you size for peaks
Fabric smooths usage instead of charging spikes instantly. Interactive operations, such as report queries and SQL or KQL queries, are spread over at least 5 minutes. Background operations, such as refreshes, Spark jobs and pipelines, are spread over 24 hours (Microsoft Learn: throttling and smoothing). Microsoft's reservation guidance says this "allows you to purchase for average workload rather than the peak" (Microsoft Learn: Fabric reservations). If your capacity was sized from a single refresh spike, it's probably too big.
3. Know what throttling really means
Going above 100% doesn't stop your capacity straight away. Fabric lets you borrow future capacity and only throttles in stages, depending on how much future capacity you've used up. Interactive requests are delayed first, then rejected. Background jobs are rejected only after a full 24 hours of future capacity has been used (throttling stages).
So short bursts above 100% are expected and are not a reason to upsize. Sustained throttling that your users can feel is the real warning sign. Even then, check items 4 to 6 before you scale up.
4. Find and fix the heaviest items
The usual suspects are:
- Semantic models refreshed far more often than anyone reads them.
- Full refreshes where an incremental refresh would do.
- Spark notebooks running on oversized sessions.
- Dataflows that copy the same source several times.
- Pipelines that keep polling for data that hasn't changed.
Rank items by CU seconds in the Metrics app and fix the top five first. Each fix lowers the baseline you'd otherwise pay to cover.
5. Move refreshes out of business hours
Background operations are smoothed over 24 hours, but they still add to the load. Interactive users feel the effect when that load piles up during the working day. Moving large refreshes and batch jobs earlier or later leaves headroom for report users without a bigger SKU.
6. Separate workloads that shouldn't share a capacity
An organisation can run as many capacities as it needs (Fabric licenses). Development and test workspaces, data engineering jobs and executive reporting rarely need the same size or the same hours. A small capacity for development that you pause outside working hours, next to a right-sized production capacity, often costs less than one large shared capacity. It also stops a runaway notebook from throttling your board reports.
7. Pause capacities that don't need to run all the time
You can pause and resume F capacities. While a capacity is paused it isn't billed, and you can schedule pause and resume with Azure Automation runbooks or the REST API (Microsoft Learn: pause and resume). Two caveats from the documentation:
- When you pause, any outstanding smoothed usage and overages are added to your bill at that point.
- Content on a paused capacity isn't available.
Pausing suits development, test and batch-only capacities best. It doesn't suit capacities that serve reports at all hours.
8. Reserve only the steady baseline
Fabric capacity reservations run for one or three years and are bought in single-CU increments. The discount is applied hour by hour, and any reserved CUs you don't use in an hour are lost; they don't carry over. A reservation covers capacity only, not storage or networking (Fabric reservations).
The practical rule is to reserve the CUs you run around the clock and leave anything you pause or scale on pay-as-you-go. Reserving 64 CUs for a capacity you pause every night means paying for reserved hours you never use. For current rates, see the official Fabric pricing page.
9. Check the F64 licensing threshold before you downsize
Licensing changes at F64. On F64 or larger, users with a free Fabric licence and a viewer role can view Power BI content. Below F64, every viewer needs a Power BI Pro or Premium Per User licence (Fabric licenses).
So a move from F64 to F32 can save on capacity and still cost you more overall if hundreds of report viewers then need Pro licences. Do the sum both ways before you decide. Many P1 to F64 migrations stay at F64 for exactly this reason. Others can go smaller because their viewers are already licensed.
10. Plan the P to F migration on your own numbers
Microsoft is retiring Power BI Premium per-capacity SKUs and recommends F SKUs instead (Fabric licenses). The migration is a good moment to resize. Don't assume P1 has to become F64. Measure what the workload uses, apply checks 4 to 6, and only then choose the size, the reservation and any pause schedule.
A quick decision table
| What you see | Do this first |
|---|---|
| Short spikes above 100%, few user complaints | Nothing. Smoothing is working. |
| Sustained throttling during business hours | Fix the top items and move refreshes (checks 4 and 5) |
| Capacity idle at night or at weekends | Split capacities and pause the non-production ones (checks 6 and 7) |
| Stable usage around the clock | Reserve the baseline (check 8) |
| Thinking of going below F64 | Compare Pro licence costs first (check 9) |
Want these checks done for you?
CostFabric runs fixed-price, read-only cost audits for Microsoft Fabric capacities. We need access only to Capacity Metrics and item metadata. You get a costed list of changes, including SKU size, reservations, pause schedules and the items to fix. The audit pays for itself, or you get half back.