Power BI licensing in 2026: Pro, Premium Per User or Fabric capacity, with the break-even arithmetic

Licensing is the first place money leaves an analytics programme for no return, and it leaves in both directions. Some organisations buy an F64 capacity for 40 report readers because a reseller described it as "the enterprise option". Others keep 900 people on individual Pro licences long after a capacity would have been cheaper, because nobody ever did the arithmetic.

This is the arithmetic. It is not complicated, but it depends on three numbers most people have not counted: how many people read reports, how many build them, and which capacity-only features you actually need rather than would quite like.

The four things you are choosing between

Strip away the naming and there are four meaningful options.

Those figures follow the 2025 price revision and are US list. Sterling, euro and Swiss franc list prices track them with regional adjustment, and any enterprise agreement worth signing lands below list. Treat every number here as an order of magnitude and price from the current rate card.

The break-even calculation, done properly

The single most useful number in Power BI licensing is the point at which an F64 capacity becomes cheaper than licensing each reader individually. F64 is the threshold SKU: below it, every person who opens a report still needs their own Pro licence, which means a small capacity gives you features but no licence relief.

The naive calculation divides the F64 price by the Pro price and produces a reader count. The result is wrong in both directions, for two reasons.

Reason one: you pay less than list. Volume agreements, education and non-profit pricing, and reserved capacity all move the numbers. Reserved F64 is roughly 40 per cent cheaper than pay-as-you-go, which alone shifts the break-even point by hundreds of users.

Reason two: authors still need licences. On most capacities, people who publish content still need a Pro or PPU licence even when readers do not. A hundred authors on Pro does not disappear because you bought a capacity.

Worked properly, with reserved capacity and a realistic discount, F64 tends to become cheaper somewhere between 350 and 600 readers. Below roughly 300 readers it is very hard to justify on cost alone. Above roughly 700 it is usually obvious. Between those, it comes down to whether you need capacity features anyway.

When PPU is the right answer

PPU is the most under-used option and the most misunderstood. It gives a user nearly all capacity features without buying a capacity: larger models, more frequent refresh, deployment pipelines, paginated reports, XMLA endpoints.

PPU makes sense when a small number of people need capacity features and a large number do not. A finance team of twelve building a 6 GB model with hourly refresh, serving 80 readers, is a textbook PPU case, except for one trap that catches people regularly.

The trap: content in a PPU workspace can only be consumed by other PPU users. There is no mixed mode where PPU authors publish to Pro readers. So the twelve-person finance team example only works if the 80 readers are also on PPU, which at around US$24 each is more expensive than an F-SKU would be. Where readers must stay on Pro, PPU authorship does not help you.

Used correctly, PPU is for teams whose members are both the authors and the audience: an analytics function, a risk team, a planning group. Used incorrectly, it is a licence you buy twice.

What capacity actually buys beyond licences

Setting licence relief aside, a capacity gives you things per-user licensing cannot:

• Model size beyond the per-user limits, which matters once a semantic model passes a few gigabytes compressed.
• Direct Lake, which reads Delta tables in OneLake with no import refresh. This is genuinely transformative for large, frequently landing tables, and irrelevant if your data fits comfortably in an import model.
• Data engineering in the same tenancy: pipelines, notebooks, warehouses and lakehouses drawing on the same capacity rather than a separate Azure subscription with separate billing.
• Higher refresh frequency than the standard eight scheduled refreshes a day.
• Deployment pipelines for promoting content across development, test and production.

That list is also the honest test of whether you need one. If you read it and recognise nothing you are currently blocked on, you do not have a capacity requirement. You have an unmet preference.

The four ways organisations overspend

One: buying capacity for prestige. An F64 bought for a 60-reader estate costs five figures a year more than the equivalent Pro licences and delivers features nobody has asked for. We have seen this three times; in each case the purchase preceded any workload analysis.

Two: keeping everyone on Pro past the break-even. The mirror image. A 1,200-reader estate on individual Pro licences is spending roughly double what a reserved F64 would cost. This usually persists because nobody owns the licence review.

Three: pay-as-you-go capacity left running. Fabric capacity can be paused. A development capacity running 24/7 when it is used three days a week is a direct, avoidable cost, and pausing it is a scheduled job, not a project.

Four: PPU as an accident. Individual users granted PPU to unblock one feature, never reviewed, with the organisation paying PPU rates for people who use nothing beyond Pro functionality. A licence audit against actual feature usage normally finds several of these.

How to work out your own answer in an afternoon

You need four counts and one decision.

1. Count readers. People who open reports and never publish. Get this from the activity log via the admin API, not from an assumption. In our experience the real number is usually lower than IT believes, because a meaningful share of licensed users have not opened anything in 90 days.
2. Count authors. People who publish. They need Pro or PPU regardless of capacity.
3. List blocked features. What are you currently unable to do? Model size, refresh frequency, Direct Lake, paginated reports, XMLA write. Be strict: "would be nice" is not blocked.
4. Establish your actual price. Your agreement price for Pro and PPU, and reserved versus pay-as-you-go capacity pricing for your region.
5. Decide on reservation. A one-year reservation is around 40 per cent cheaper and is the right call if the capacity is for production. For experimentation, pay-as-you-go with pausing is cheaper.

Then compute three totals: all-Pro, Pro-authors-plus-capacity, and all-PPU. The cheapest number that also unblocks your list is the answer. It takes an afternoon, and it is the highest-return afternoon in the whole programme.

Capacity sizing is a separate question

Choosing a capacity and sizing it are different decisions, and conflating them is how people end up throttled. Capacity units are consumed by both interactive queries and background operations such as refresh, and Fabric smooths and bursts consumption over time, which means a capacity can appear fine for weeks and then throttle at month end when everyone opens the close pack at once.

Size from measured consumption: profile each workload for compute shape, concurrency and peak hours, then validate on a short-lived trial capacity with your real data. The output should be a sizing model stating expected utilisation at launch, at double the readers, and the point at which you would need the next SKU. We cover this in Microsoft Fabric: the build-or-wait decision.

What we would tell you on a call

For most organisations between 50 and 500 staff: Pro for everyone, PPU for the handful of people who need capacity features and consume their own content, no capacity. Review annually against the activity log.

For organisations with several hundred readers and a real data engineering requirement: reserved F64, Pro for authors, and a capacity metrics dashboard watched monthly rather than at the point of failure.

For everyone else: do the afternoon of arithmetic above before you talk to anyone who sells licences, including us. We take no commission on your Microsoft spend, which is precisely why we are comfortable writing the version of this article that costs us revenue.

Licensing across a group of companies

Multi-entity groups get this wrong more often than single companies, usually by buying per entity.

Power BI licensing follows the Microsoft 365 tenant, not the legal entity. A group with six subsidiaries in one tenant licenses people once; the same group split across six tenants licenses six times and cannot share a semantic model without cross-tenant plumbing. Where a group is mid-consolidation, with some entities migrated into the parent tenant and some not, the licensing cost of the un-migrated entities is a genuine and quantifiable argument for finishing the migration.

Two related points that come up in every group conversation:

• Guest users. External guests can consume content, but the licensing responsibility depends on configuration and agreement type. Check it deliberately rather than assuming a guest is free, because the audit position is worse than the cost.
• Service principals. Automated refresh, deployment and administration through service principals do not consume user licences, which is one more reason to automate publishing rather than have a named person do it.

What changes when you add data engineering

If you are only running Power BI, the licensing decision is the whole cost conversation. The moment pipelines, notebooks or a warehouse enter the picture, the comparison changes shape, because that compute has to come from somewhere.

Three options, with different billing behaviour:

That third row is the one worth sitting with. On a shared capacity, a badly behaved notebook and a Monday-morning executive report draw from the same pool. Capacity smoothing absorbs a lot of that, but not all of it, and the failure is visible to exactly the audience you least want to disappoint.

A licensing review checklist

Run this annually. It takes a morning and it has never failed to find money.

1. Pull 90 days of activity from the admin API. List every licensed user with zero views.
2. Compare PPU holders against PPU feature usage. Anyone not using a capacity feature should be on Pro.
3. Check guest and external accounts against current engagements.
4. List every capacity and its utilisation. A development capacity averaging under 10 per cent should be paused on a schedule or dropped a SKU.
5. Check reservations. Any production capacity not on a one-year reservation is paying roughly 40 per cent more than it needs to.
6. Re-run the break-even against your current reader count, in both directions.

The output is a one-page memo with a number on it. In our experience that memo pays for the morning several times over, and it is the kind of work an internal analyst can do perfectly well without a consultancy, which is why it is written down here rather than sold.

If you want the arithmetic done on your own estate, a technical review will produce it alongside the rest of the picture, and you keep the numbers whatever you decide to do next.