A team with 40 analysts can pay less for Power BI than a team with 10 if their report usage is staggered, and the opposite is true if usage spikes. By the end of this article, you’ll be able to model your team’s real-world report access patterns and pick the right mix of Pro, Premium Per User (PPU), or Fabric Capacity SKUs—without falling for the “average concurrency” trap that leads to unexpected throttling or overspending.
Bursting Isn’t Just a Peak: Why Concurrency Patterns Drive Real Costs
The most common mistake Power BI teams make is treating average user counts or “typical usage” as the key driver for licensing. In reality, Microsoft’s capacity enforcement—whether Pro, PPU, or Fabric F-SKU—responds to actual concurrent activity in 5-minute windows (“burst”), not smoothed averages across the day.
- Pro/PPU: Each user must have a license; there is no pooling. If 100 users need to view content, you must license all 100, even if only 10 are active at a time. However, Pro/PPU are not throttled by backend capacity—just by user count and feature gating.
- Fabric Capacity: Capacity is pooled and shared. Any user with Viewer rights can access content if the workspace is assigned to a capacity. But the actual backend resources (measured in Capacity Units, or CUs) are finite. If too many users trigger heavy queries at once, throttling or queuing occurs.
The non-obvious gotcha is this: a team of 40 with usage spread thinly over the day can often run on a much smaller (and cheaper) capacity than a team of 10 who all hit refresh at 9:00am sharp—because smoothing minimizes concurrency peaks, while bursting amplifies them and exposes you to throttling or the need for higher SKUs.
How Microsoft Measures Usage for Throttling
Capacity units (CUs) in Fabric are consumed by query and refresh operations. The enforcement is on “active” backend processing at any given moment—not daily totals. If too many complex visuals are loaded at once, even brief spikes (“bursts”) trigger throttling, regardless of what the rest of the day looks like.
Key point: Sizing for the mean is rarely enough. Sizing for the 95th percentile of concurrency is closer to reality, especially if you have known spikes (e.g., Monday morning executive reviews).
Why the “One License Per User” Rule Fails for Shared Capacity
It’s tempting to assume that Pro or PPU is always cheaper for small teams, or that Fabric capacity only makes sense for hundreds of users. This is outdated. There are real cases where a well-sized F-SKU is the lower-cost, higher-reliability choice—even for teams under 20—if usage is staggered, and cases where Pro/PPU is the only practical answer for spiky or unpredictable demand.
- Pro/PPU: Predictable cost, but no pooling. Cost scales linearly with user count, regardless of usage pattern.
- Fabric F-SKU: Pooling allows high user counts, but concurrency spikes define your performance (and cost). You pay for headroom to avoid queueing, not just for “total users.”
Most teams get this backwards: they look at total users, not concurrent load. You can have hundreds of infrequent users sharing a single capacity—if their access is naturally staggered. But a handful of power users with overlapping, heavy workloads can saturate even a generous capacity.
Worked Example: Two Teams, Same Users, Different Costs
Take two teams of 20 users each. Both run the same heavy Power BI reports, but with very different usage patterns:
- Team A (smoothed): Each user logs in at a random time during the day. Average concurrency is 3, peak is 5.
- Team B (bursty): All 20 log in and hit “refresh” at 9:00am for a daily meeting. Peak concurrency is 20, sustained for 10 minutes.
If both teams buy Pro or PPU licenses, cost is identical: 20 licenses. But if both move to a Fabric F2 capacity (2 CUs), only Team A is likely to see smooth performance; Team B will hit throttling or queued visuals every morning unless they buy a much larger capacity (say F8 or above, depending on report complexity).
That means Team B either needs to:
- Pay several times as much for higher capacity (negating pooling savings), or
- Enforce staggered access (hard to police, often impractical), or
- Accept queued reports—users waiting tens of seconds or more for visuals to load.
For Team A, the pooling efficiency is real: they can add more users with minimal impact, as long as usage stays smooth. For Team B, capacity “pooling” is a mirage unless they solve the burst.
How to Model Your Team’s Real-World Demand: Beyond Licensing Calculators
The official calculators assume either full concurrency or uniform usage, but neither matches real team behaviour. To right-size your licensing and avoid surprise throttling, you need a concurrency histogram: how many users are active in each 5-minute window, and how heavy are their workloads?
- Gather report access logs: Usage metrics from the Power BI Service or Audit Logs can be exported. Look for “View Report” or “Query Refresh” events, with timestamps.
- Build a concurrency histogram: For each 5-minute window, count unique users kicking off reports or refreshes. Plot the distribution.
- Estimate backend load: Not all reports are equal. A simple slicer hit costs little; a DirectQuery visual or composite model can spike CPU and memory. Mark heavy reports as “high CU” and model accordingly.
What matters most:
- Your 95th percentile concurrency—not just the mean.
- The aggregate “weight” of workloads in the peak window.
- Whether peaks are predictable (scheduled meetings) or random (ad hoc analysis).
This modelling often reveals that a team assumed to need F8 or higher can run on F2 or F4 with minimal queueing—if they can smooth their access. Or, it proves that a handful of power users drive peak load, making per-user licenses cheaper and more predictable.
Naive Capacity Planning That Fails
-- Naive: Assume 100 users, 10% concurrency, each report is lightweight
Required_CUs = (100 users * 0.10) * 1 CU_per_user = 10 CUs (F10)
-- Reality: If 15 users hit a complex report at once, and each triggers 2 CUs of load:
Required_CUs_peak = 15 users * 2 CU_per_user = 30 CUs (F32 or F64)
The naive approach ignores real concurrency and workload weight. The fix is to size for the actual observed or modeled peak, not a guess at “average concurrent users.”
Optimizing for Cost: When to Prefer Pro, PPU, or Fabric Capacity
There is no universally “cheapest” option. The right answer depends on how your team’s usage maps to the licensing and capacity model:
- Choose Pro or PPU: When each user is a heavy, unpredictable analyst; when you can’t guarantee smoothing; when features gated to PPU/Pro (like Personal Workspaces or ML) are needed; or when per-user costs are low compared to pooled capacity.
- Choose Fabric Capacity (F-SKU): When usage is naturally staggered, most users are viewers, and you can model or enforce concurrency. This is especially effective for external sharing or large “mostly viewer” teams.
- Avoid: Assuming capacity pooling will always save money. If your peak concurrency or report complexity is high, Fabric can be more expensive than Pro/PPU for the same service level.
Field parameters, calculation groups, and other advanced features now supported on capacity SKUs can tip the balance, but only if you get concurrency modeling right. Overprovisioning to “be safe” is rarely cost-effective; underprovisioning leads to user frustration and lost confidence.
Checklist: Steps to Right-Size Your Power BI Licensing
- Export actual usage logs and build a concurrency histogram per 5-minute window.
- Tag heavy reports and estimate their backend CU usage (test with representative loads).
- Model your 95th percentile concurrency and workload weight—not the mean.
- Compare total cost of Pro/PPU (per user) vs. F-SKU (per capacity) at your modeled workload.
- Test burst scenarios, not just smooth usage. If you can’t stagger usage, bias toward per-user licensing or larger capacity.
- Document queueing or throttling events, if any, to ground future sizing decisions.
Ignoring concurrency is the most expensive mistake you can make—either in wasted spend or hidden throttling.
Act on What Your Usage Data Actually Says
Don’t let “average usage” or total user counts drive your licensing. Model your team’s actual concurrency and workload patterns, and size for the peaks that matter. If you see bursty usage you can’t smooth, favor per-user licensing or overprovisioned capacity. If your usage is naturally staggered, pool aggressively with F-SKUs. The tooling is there; the trap is assuming one model fits all.