A Power BI capacity is a fixed monthly commitment that replaces per user licensing for everyone it serves, including the large population of viewers who then need no individual license at all. That makes it the cheapest home for a broad consumption audience, but only if the capacity is sized correctly. Oversize it and you pay for compute units that sit idle every hour of the day. Undersize it and reports throttle, queries queue, and the business loses trust in the platform faster than any saving can justify. Sizing is not a guess and it is not a vendor recommendation pulled from a generic sizing chart. It is a workload measurement. The correct SKU is the one whose compute capacity covers your real peak load with a defined margin, sustained over a representative period, and nothing larger. We size to the measured ninety fifth percentile of demand with headroom for growth, then revisit as the workload moves, because a capacity bought for last year's usage is almost never the right capacity for this year's.
A capacity decouples cost from headcount. Instead of paying per author and per viewer, you pay for a pool of compute, and an unlimited number of viewers consume from it without a per user license. The economics flip once the consumption audience is large enough, which is exactly why sizing matters: the capacity only wins if it is sized to deliver that consumption without breaking.
Under per user licensing, every person who reads a report holds a Pro or Premium Per User seat. On a capacity, content published to a capacity backed workspace is consumed by any viewer in the organization with no per user license required. For an estate with thousands of report consumers and a few hundred authors, this is the single largest lever in the entire Power BI bill.
A capacity has a fixed pool of compute units. Exceed it and the platform throttles: reports slow, refreshes queue, and interactive queries stall. Throttling is the failure mode that turns a cost saving into a credibility problem, and it is the reason undersizing is far more dangerous than the saving it appears to deliver. The correct size is the one that never reaches this state at real peak.
Correct sizing is a measurement exercise, not a sales conversation. Three inputs determine the right SKU, and each one comes from your own telemetry rather than a generic chart. Get these right and the capacity is both cheaper and reliable.
The capacity must cover the busiest moment, typically the morning window when reports refresh and the largest audience opens dashboards at once. We measure the ninety fifth percentile of compute demand over a representative period rather than the daily average, because the average hides the peak that causes throttling. Sizing to the average guarantees failure at the hour that matters most.
Scheduled and on demand refreshes are heavy, bursty consumers of capacity. A large model refreshing frequently can dominate the pool and collide with interactive use. We map the refresh schedule against the interactive peak, stagger where possible, and size so the two together stay inside the SKU rather than fighting each other into a throttle.
A capacity sized exactly to today throttles the moment usage grows, which it always does as adoption spreads. We size with a defined margin above measured peak so the capacity absorbs organic growth without an emergency upgrade, and we set the review cadence to step the SKU up or down as the real workload moves rather than locking in a number that ages badly.
The correct position is not a one time SKU selection. It is a sizing decision plus a discipline that keeps the capacity matched to a moving workload, so it never drifts into either idle overspend or throttling underspend.
We model your measured peak, refresh pressure, and growth margin against the capacity tiers and the per user alternative side by side. The recommendation is the smallest SKU that covers real peak with headroom, compared directly to what per user licensing would cost the same population. Where the consumption audience is large, the capacity wins decisively and we document the breakeven so the decision survives scrutiny from finance. Where it does not, we say so and keep you on per user rather than selling a capacity that does not pay back.
Capacity metrics show exactly how much of the pool is consumed and when throttling approaches. We set the monitoring so overload is visible before users feel it, and we revisit the SKU on a defined cadence. A capacity that was correct last year may be oversized after a consolidation or undersized after a new rollout. Treating the SKU as a living number, stepped up or down on evidence, is what separates a capacity that keeps saving from one that quietly becomes the wrong size and stays there.
The three measurement inputs, the peak versus average trap that causes throttling, and the capacity versus per user breakeven model that tells you when a capacity actually pays back. Sent on request.
We measure your real peak load, refresh pressure, and growth, model the capacity tiers against per user licensing, and recommend the smallest SKU that never throttles. Then we set the monitoring and review cadence that keeps the capacity matched to a moving workload year over year.