Power BI Licensing and Capacity Planning: Pro, PPU or Fabric

When someone asks me "Pro, PPU, or Fabric?" they usually want a single answer. There is no single answer, because the question hides two different decisions. One is who is allowed to author and consume content. The other is how much compute your reports actually burn when people click on them. Pick the license first and you will over-buy or throttle. Size the load first and the license almost chooses itself.

Why this is a sizing question, not a licensing one

Per-user licensing (Pro and Premium Per User) charges for seats. Capacity licensing (Fabric F-SKUs and Embedded) charges for a fixed pool of compute that any number of viewers can share, provided the content lives in a workspace backed by that capacity. So the real variables are not "which tier is cheapest per head." They are: how many people author, how many only view, how heavy your models are, how often they refresh, and whether people outside your tenant need access.

Get those five numbers first. Then the pricing tiers stop being a menu and become arithmetic. Prices below are indicative and move; treat every figure as a planning estimate, confirm against the current Power BI pricing page , and recheck every quarter because Microsoft revises SKUs and list prices without much notice.

The four options and what each unlocks

There are four buying paths, and they are not tiers of the same thing. Pro and PPU are per-user. Fabric F-SKUs and Embedded are capacity. Here is what each one actually gives you.

• Power BI Pro (per user). The baseline for publishing and sharing inside your organisation. Every author needs it. Every viewer needs it too, unless the content sits on a capacity. Good for small teams where everyone touches reports.
• Premium Per User (PPU, per user). Pro plus the premium feature set (larger models, more frequent refresh, paginated reports, deployment pipelines) but scoped to the individual. Everyone who touches PPU content needs a PPU license, so it fits a small, all-power-user analytics team, not a broad viewer base.
• Fabric capacity (F-SKU). A shared compute pool. Content in a Fabric-backed workspace can be viewed by users on free licenses, so viewers stop being a per-seat cost. This is the lever that changes the maths for any operation with a lot of read-only consumers.
• Power BI Embedded. Capacity aimed at customer-facing apps, where you embed reports in your own product or portal and your end customers never log into Power BI at all. Different billing model, meant for ISV and external-app scenarios rather than internal reporting.

Figures are indicative planning estimates as of 1 August 2026 and vary by region, agreement and SKU. Confirm before you commit.

A sizing example: a 400-person operator

Take a facilities and operations business of 400 staff. When I break down who actually does what with reports, it looks like this: 35 report authors who build and publish, 260 viewers who only open dashboards, and 9 external client contacts who need to see a handful of shared reports from outside the tenant. The remaining staff never open Power BI at all, which is a reminder to license the people who use it rather than the headcount on the org chart.

Path A, all-Pro:

Every author, every viewer and every external guest needs a Pro seat. That is 35 + 260 + 9 = 304 seats. At roughly USD 14 each, you are near USD 4,250 a month, and it climbs linearly with every new viewer. The 245 people who never build anything are paying full author price to click.

Path B, Fabric capacity with free viewers:

Put the shared content on a Fabric capacity. The 35 authors still need Pro to publish (roughly USD 490 a month). The 260 viewers move to free licenses because the content is capacity-backed, so their per-seat cost goes to zero. The 9 external contacts can view through the same capacity. Your monthly bill is now the 35 Pro seats plus the F-SKU. Whether that beats Path A depends entirely on which F-SKU the interactive load actually needs.

Running the capacity after you buy it

A per-user license is fire and forget. A capacity is something you operate, and this is the part teams underestimate. Buying the F-SKU is day one; keeping it healthy is every day after. A capacity has a finite compute budget, and everything that touches it, refreshes, dataflows, paginated renders and every interactive query, draws from the same pool. When the pool runs dry, users feel it as slow visuals or delayed refreshes, so someone needs to own that budget the way you would own any shared resource.

• Watch the metrics app. Install the Fabric Capacity Metrics app on day one. It shows compute consumption, queue delays and throttling over time. If you are not looking at it, you are flying blind on the one asset you just paid for.
• Find the model causing throttling. Throttling is almost never the whole tenant; it is usually one or two heavy models or a badly timed refresh. The metrics app lets you drill to the item and time window burning the budget. Fix the offender before you buy more capacity.
• Stagger refresh schedules. The classic self-inflicted overload is ten datasets all refreshing at 06:00. Spread them across the morning so refresh compute does not collide with the first wave of interactive users. Refresh is background load; interactive clicks are what your viewers feel.
• Autoscale versus overload. Fabric can smooth short spikes by borrowing future capacity, and you can add autoscale so brief peaks do not throttle users. But autoscale costs real money and can mask a genuinely undersized capacity or a broken model. Use it as a shock absorber, not as a substitute for fixing the model or right-sizing the SKU.

The mechanics of all of this, smoothing, throttling thresholds and SKU behaviour, are documented in the Power BI capacity docs . Read them before you size, not after your first throttling incident.

A five-question pre-purchase checklist

Before you sign anything, answer these five. If you cannot, you are not ready to buy.

1. How many people build versus how many only view? The author-to-viewer ratio decides whether per-user or capacity is cheaper.
2. How big are your largest models, really? If nothing needs more than 1 GB, Pro may cover the features you use. If models are large or need frequent refresh, you are into PPU or capacity.
3. Do you need paginated reports? If pixel-perfect operational documents matter, Pro alone will not do it; you need PPU or a capacity.
4. Does anyone outside the tenant need access? External viewers behave very differently on per-user versus capacity, and that difference can flip the whole calculation.
5. What is your typical interactive concurrency? Not your peak, your normal weekday mid-morning load. Size the capacity to that, and treat peaks as an autoscale question.

Conclusion

Pro, PPU and Fabric are not a good-better-best ladder. They answer different questions. If almost everyone authors, per-user is honest and simple. If you have a big read-only audience, capacity with free viewers is usually cheaper past a viewer count you can calculate. Embedded is a separate conversation for customer-facing apps. Do the sizing, run the breakeven, and the license reveals itself. If your reporting feeds off operational systems, the same discipline applies to the pipelines behind them, whether you are connecting Power BI to IBM Maximo or wiring Business Central into Power BI.

Independence note: I am not a Microsoft reseller and I earn nothing from which SKU you choose. The prices here are indicative planning estimates verified as of 1 August 2026; Microsoft revises them without notice, so confirm current figures and recheck at least quarterly before you budget.