One User. Two Clicks. 553,000 Compute Units.

How to keep your Microsoft Fabric capacity under control

Introduction

Microsoft Fabric promises a unified analytics platform, one capacity, one bill, everything in one place. But that simplicity comes with a catch: every workload on your capacity competes for the same pool of compute units (CUs). When those CUs run out Microsoft Fabric first takes an advance on your future CUs. Once those are exhausted too Fabric starts slowing down your workloads a mechanism called throttling. In the most cases, jobs get cancelled entirely. In Fabric you pay for what you consume: Compute Units (CUs) for processing, storage for your data in OneLake and optionally overage and networking costs.

In many organizations that start using Fabric in an organic way without clear governance in place from the beginning, we see the same pattern: Capacity peaks, throttling incidents start reoccurring and the first instinct is to upgrade your capacity. In most cases the root cause isn’t an undersized capacity, it’s an unoptimized one.

In this post we walk through a real-world analysis of a retail customer running on a F64 capacity that was peaking at 168% utilisation. We’ll show you what was causing it, how we fixed it and what you can do upfront to keep your own Fabric capacity and your cloud bill under control.

“If you think good architecture is expensive, try bad architecture.”

Brian Foote & Joseph Yoder

You can’t improve what you can’t measure

Before any optimisation can happen, you need visibility. In Microsoft Fabric that means one tool: the Fabric Capacity Metrics app. Without it you’re flying blind, guessing which workloads are expensive, which refreshes are colliding and why your capacity spikes at 3 AM.

 Figure 1 — The Fabric capacity metrics compute overview

To make this concrete we walk through a real-world analysis. Our retail client had been running Fabric for over a year when they first noticed consistent throttling during peak hours. Once we connected the Metrics app to the customer’s F64, two distinct peak patterns emerged immediately:

• Night-time peaks (03:00–05:00 AM): multiple scheduled dataflows and dataset refreshes running simultaneously, competing for the same compute units.
• Daytime peaks (12:00–15:00 PM): manual on-demand refreshes triggered by users directly from the workspace during office hours.

Figure 2 – The Fabric capacity metrics app revealing peak patterns: scheduled night-time collisions and manual daytime refreshes.

The table below shows the top consumers over a 6-day period, ranked by total CU consumption:

Item	Peak Type	CU (6 days)	Priority
Dataset (Semantic Model)	On-demand (manual)	854,993	CRITICAL
Dataset (Semantic Model)	Scheduled + On-demand	748,050	CRITICAL
DataflowFabric	Dataflow query	455,055	HIGH
DataflowFabric	Dataflow query	138,798	HIGH
SynapseNotebook	Notebook background	329,266	MEDIUM

Figure 3 – Top CU consumers over a 6-day period ranked by total CU consumption

The single largest item a large semantic model, consumed 553,160 CUs nearly 10% of an F64’s entire daily capacity (5.5 million CU), triggered by one click from one user. The same user did it again on Monday. And the Tuesday before that. You can’t improve what you can’t measure.

What was actually going wrong

Beyond the individual workloads, four structural issues explained why peaks consistently exceeded the capacity limit. These aren’t unique to this customer we see them across almost every Fabric deployment that runs into capacity trouble.

1. Users could trigger on-demand refreshes directly

Users had direct workspace access not through a published Power BI App, but the workspace itself. Every user with Contributor or higher access could hit Refresh on any semantic model, at any time, regardless of what else was running. One user was doing exactly that, every working day, on a model that took 2 hours and 553,000 CU to reload.

2. No incremental refresh on large semantic models

Both critical models did full reloads on every refresh, every table, every row, from scratch. Certain tables had a Calendar Week column, a perfect candidate for incremental refresh. None of it was configured.

3. Pre-production (preprod) workloads running on production capacity

Two heavy SAP BW dataflows ran in a Preprod workspace but consumed the shared production F64. Over 6 days, these alone accounted for 594,000 CU – the second largest cost driver on the capacity. Is this level of consumption normal for SAP BW extractions? In isolation, yes these extractions are inherently heavy. The problem here was not the volume itself but that two overlapping extractions were pulling the same data independently doubling the CU cost with no added benefit.

4. Duplicate extractions from the same source

Both preprod dataflows reading from the exact same SAP BW cube on the same server with overlapping data, two separate heavy extractions where one consolidated write to a shared Lakehouse table would have been sufficient.

The fixes – Do’s and don’ts

Each root cause has a clear fix. Here’s what to do — and what to avoid — for each one.

On-demand refreshes

✓   DO	X DON’T
Publish semantic models as Power BI Apps – App viewers cannot trigger manual refreshes	Don’t give end users Contributor access to workspaces containing large semantic models
Investigate why users refresh manually. Often the scheduled refresh just needs a timing adjustment	Don’t assume users won’t click Refresh – they will, especially if reports feel stale

Incremental refresh

✓   DO	X DON’T
Enable incremental refresh on any large table with a date or week column, start with your biggest models first	Don’t do full reloads on tables with years of historical data when only the last few days change
Distribute scheduled refreshes, avoid round-hour starts (02:00, 03:00) where multiple jobs collide	Don’t rely on autoscaling to absorb unoptimised refresh patterns – it treats symptoms, not causes

Preprod on production capacity

✓   DO	X DON’T
Assign Preprod workspaces to a dedicated, lower-tier capacity	Don’t let Preprod and Production share the same capacity without isolating their schedules
If a dedicated Preprod capacity isn’t available yet, schedule Preprod workloads outside office hours	Don’t wait until throttling happens to separate environments, set the boundary from day one

Duplicate source extractions

✓   DO	X DON’T
Merge overlapping source extractions into a single shared Lakehouse table	Don’t let two dataflows query the same source with overlapping data just because they serve different teams
Move reference data (like filter lists) from SharePoint files to Lakehouse, no API call on every refresh	Don’t optimise dataflows in isolation, look at the full picture across all workspaces on the capacity

Before you even hit a peak – Upfront cost control

Fixing an existing problem is one thing. Not creating it in the first place is better. Here are the cost levers that matter before and during your Fabric deployment.

Start with the right SKU and the right region

Use the Fabric Capacity Estimator to model expected CU consumption before committing to a SKU. Also: West Europe Fabric pricing is meaningfully higher than North Europe. If your data residency allows it, North Europe is the more cost-effective choice.

Reservations: 41% savings for predictable workloads

Pre-committing to 1 or 3 years of usage saves roughly 41% over pay-as-you-go. On a capacity running 24/7, a 1-year reservation breaks even after approximately 7 months, whilst the remaining 5 months are effectively free. You also lock in today’s price for 12 months, protecting against future price increases.

Reservations can be cancelled, but refunds come as Azure credit – not back to your bank account. Factor this in before committing.

The F64 threshold: free Power BI licenses

This links directly back to how you use your capacity: at F64 and above Microsoft includes Power BI Premium per-user licenses for report consumers at no extra cost. For organisations with many report viewers this can make an F64 more cost-effective than combining a smaller capacity with individual Power BI Pro licenses.

OneLake cache: the hidden cost most teams miss

OneLake cache storage is priced at ~$0.24/GB per month – roughly 10 times more expensive than hot storage and 60 times more than cold. Most teams don’t actively manage cache retention, so data sits in cache long after it’s needed. Review your OneLake shortcut caching settings and set appropriate retention windows.

What’s next: configuring the tenant itself

The fixes above address what was already running. But the deeper question is how you set up Fabric so these problems don’t start in the first place.

That’s what our colleague Bilel is covering in an upcoming post, tenant-level governance: environment separation, dedicated capacity allocation for specific workloads and why training your teams matters just as much as any technical safeguard.

Keep an eye out!

“Most tenant misconfigurations aren’t mistakes, they’re defaults nobody revisited. That’s the gap governance is supposed to close.”

Bilel Ben Hadef, BI & Data Analytics Consultant at Lytix

It’s a feedback loop, not a one-time fix

The retail customer we worked with didn’t need a bigger capacity. They needed to adjust how they were using their existing F64 capacity. By addressing the four root causes, they brought peak utilisation well below the throttling threshold without changing their SKU.

The broader lesson: 20 to 40% of cloud costs are typically optimisable. The compute units are there. The question is whether you have the visibility to see where they’re going and the discipline to act on it continuously.

Three things to take away from this post: First, measure before you act, the Fabric Capacity Metrics app is non-negotiable. Second, governance gaps are almost always the root cause of capacity problems not an undersized SKU. Third, cost control is a feedback loop set it up once and review it continuously, not only when something breaks.

“Cloud cost optimization is not a finish line, but a feedback loop.”

Kristijan Shirgoski, Cloud Architect at Lytix

Key numbers from the field

168%     Peak capacity utilisation

553K CU from one manual refresh

41% Savings with 1-year reservation

7 mo Reservation break-even point

Is your Fabric capacity running hotter than it should?

We help organisations analyse their Fabric Capacity Metrics, identify the real cost drivers, and implement structural fixes before the next throttling incident.

Get in touch with us!

Written by