Friday Fabric Facts #21

Fabric Capacity, Part 2: Right-Sizing Without Overpaying or Throttling (Part 2 of a 3-part Series)

The Executive Insight

Part 1 reframed Fabric capacity as a shared throughput budget rather than a server. This issue is about the decision that follows: how big a budget do you actually need?

Most teams answer that the wrong way. They either size for the worst thing their platform might ever do, and pay for headroom that sits idle, or they pick the cheapest SKU that runs today, and spend the next quarter fighting throttling. Both are guesses dressed up as decisions.

The better answer is that right-sizing is a measurement, not a guess. And the single fact that makes it manageable is one we touched on in Part 1: because Fabric smooths consumption over time, you can size for your average load, not your peak.

Issue #21 is Part 2 of three. Part 1 was the mental model. This one is the sizing method. Part 3 is governing capacity once more than one team shares it.

Size for Average, Not for Peak

This is the idea that saves mid-market teams the most money, and the one most often missed.

On a traditional server, you size for peak. If month-end close hammers the box, the box has to be big enough for month-end every day of the month, even though most days are quiet. You pay for the spike all year.

Fabric doesn’t work that way. Smoothing spreads a spike across time (minutes for interactive work, up to 24 hours for scheduled jobs), so a sharp burst gets averaged into a flatter line. A capacity can briefly run well above 100% utilization and never throttle, because the overage is absorbed across the following timepoints.

The practical consequence: you size to carry your typical load comfortably and let smoothing and bursting absorb the peaks. Sizing for peak, the instinct everyone brings from on-prem, is exactly how you overpay.

Right-Sizing Is a Measurement, Not a Guess

The method is straightforward and it beats any sizing chart.

Start modestly. Stand up a capacity at a SKU you suspect is slightly too small rather than slightly too large. You can change the SKU up or down at any time from the admin settings, so the first pick is a starting point, not a commitment.

Measure for a couple of weeks in the Capacity Metrics App, and let a real billing rhythm run through it: the daily refreshes, the month-end close, the Monday morning report rush.

Watch the throttling charts, not just utilization. This is the part teams get wrong. Utilization above 100% does not mean you are throttled. Because of smoothing and built-in overage protection, a capacity can cross 100% repeatedly and still serve every request. The signal that you are undersized is sustained throttling, which the Metrics App reports directly. Size to the throttling, not to the scary-looking utilization peaks.

If you do hit throttling and need relief fast, you have two levers. Temporarily bumping the SKU up burns down the accumulated overage faster, because each timepoint then has more idle headroom to pay it off. There is also a capacity overage billing option that keeps things moving, but it bills at three times the normal rate, so treat it as an emergency valve, not a plan.

Where “Smaller” Stops Saving Money

Two traps make the cheapest-looking SKU the wrong choice.

The first is the F64 line. On F64 and above, anyone in your organization can view shared Power BI content without a per-user license. Below F64, every viewer needs a Pro or Premium Per User license. So dropping below F64 to save on compute can quietly add a per-seat licensing bill for every report consumer you have. For a team with a wide reporting audience, the smaller SKU can cost more all-in. Sizing is a total-cost decision, not a compute decision.

The second is the billing model. Pay-as-you-go is flexible and lets you pause a capacity to stop ongoing consumption, which is ideal for development and test capacities that don’t need to run overnight. Reserved (one-year) pricing is materially cheaper per unit and suits production capacities that run most of the time. The rough crossover is utilization: if a capacity runs the majority of the week, reserved usually wins; if it sits idle much of the time and you can pause it, pay-as-you-go usually wins. (Confirm current rates for your region before committing, since pricing varies.)

Hope for Lean Teams

You don’t need a formal capacity-planning exercise to get this right. A lean starter recipe:

Begin on pay-as-you-go at a modest SKU. Run your real workload for two weeks. Open the Metrics App and look at the throttling charts, not the utilization peaks. If throttling is rare or absent, you’re sized right or could even size down. If it’s sustained, step up one SKU and re-measure. Once the size is stable and the capacity runs most of the week, switch it to reserved to cut the rate. Keep dev and test on pay-as-you-go and pause them overnight.

That loop, measure then adjust, gets you to the right SKU faster than any upfront estimate, and keeps you there as your workload grows.

Where I Fit In

The sizing call is where Fabric budgets are won or lost. The hard parts aren’t the SKU numbers; they’re reading consumption correctly, knowing when utilization is fine and when throttling is real, and spotting the total-cost traps like the F64 line before they land on the invoice.

If you’re about to pick a SKU, or you suspect the one you have is the wrong size, and you want that decision made from your consumption data rather than a guess, let’s talk.

 

The right SKU isn’t the biggest one you can justify or the smallest one that runs today. It’s the one your measured consumption points to, with smoothing carrying the peaks and the billing model matched to how often it runs.

Next week, Part 3: what changes when several teams share one capacity, how to stop one workload from starving the others, and how to answer the CFO’s question: who is really spending this?

Isaac Truong | Founder, Allston Yale

Strategic Fabric Architecture for the Enterprise Mid-Market | Enterprise-grade analytics for $50M–$100M SMBs

Power BI | Fabric | Azure | Data Strategy

Book a 20-min Fabric diagnostic →

Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)

LinkedIn: Connect with me for daily Fabric tips

Friday Fabric Facts #21: Originally Posted on LinkedIn, June 19, 2026

Scroll to Top