Pro and Premium Per User

What it does

Two per-user licences. Pro is the baseline for anyone who publishes, shares or consumes content outside a capacity. PPU is Pro plus most of the Premium feature set, granted to the individual instead of bought as a capacity — with the catch that everyone touching PPU content needs PPU too.

Key facts

PPU includes all Pro capabilities. Holding PPU means you don't need a separate Pro licence.
What PPU adds over Pro, per Microsoft's comparison table: a 100 GB model size limit, 48 refreshes per day, XMLA endpoint connectivity, deployment pipelines, incremental refresh, advanced dataflows features including DirectQuery, AI capabilities such as AutoML, Impact Analysis and Cognitive Services, usage-based aggregation optimisation, and enhanced automatic page refresh.
What PPU doesn't get, that capacity does: multi-geo support, unlimited distribution, and Power BI reports on-premises. BYOK works on PPU only when it's enabled tenant-wide.
The model size limit is an upper bound, not a working allowance — memory is reserved for refresh and query operations, so the usable model is smaller than the headline figure.
Access to content in a PPU workspace requires a PPU licence. That covers reading reports, the XMLA endpoint, Analyze in Excel and composite models built on top.
PPU workspaces carry a diamond icon in the service.
PPU isn't required to publish into an existing Premium capacity. Pro is enough for that.
Workspaces can move between PPU and capacity. Moving back to capacity requires a full refresh of the semantic models and dataflows in that workspace.
PPU needs no memory or CPU management, unlike capacity. Admins choose feature settings but can't disable individual workloads.
Users can trial PPU individually, unless the tenant setting for trying paid features has been turned off.

When to use / skip

PPU is for a small, self-contained group that needs Premium features and shares almost exclusively with each other. A finance team of a dozen people running a large incremental-refresh model, publishing to nobody outside the team — PPU fits that perfectly and costs far less than the smallest capacity that would carry them.

Stop and think the moment distribution enters the picture. The consumption rule catches nearly everyone: content in a PPU workspace is only accessible to PPU holders. A client who buys twelve PPU licences for the modelling team and expects two hundred people to read the output has bought the wrong thing. At that point you're either putting the content on capacity or paying for two hundred PPU licences, and only one of those is sensible.

Configuration decisions

Whether the audience for PPU-built content is closed or open. This is the whole decision, and most others follow from it.
Whether the driver is a specific feature — XMLA, larger models, more refreshes — or a general sense that Pro isn't enough. Name the feature; it usually clarifies whether capacity is the real answer.
Whether PPU is a permanent shape or a bridge to capacity, and if it's a bridge, what triggers the move.
Whether admins allow individual trials, because that determines whether PPU spreads by request or by policy.
Who holds PPU for automation and service accounts, given the XMLA multi-user rules on PPU workspaces.

Gotchas

The consumption rule is the classic. "We'll build in PPU and share with everyone" doesn't work outside capacity, and clients discover it at UAT.
Moving a workspace back from PPU to capacity forces a full refresh of everything in it. On a large incremental model that's a long, expensive operation that nobody planned for.
The 100 GB figure is an upper bound with refresh overhead subtracted. Sizing a model close to it is asking for refresh failures.
BYOK on PPU only works if it's tenant-wide, which is a bigger decision than the team asking for PPU usually has authority to make.
Individual trials mean PPU can appear in a tenant without anyone deciding to buy it, and then content quietly starts depending on PPU-only features.

Consultant notes

Ask "who reads this?" before "what do you need?". The answer to the first question decides PPU versus capacity more reliably than any feature comparison.
Where PPU is genuinely right, document the boundary — which workspaces are PPU and what may not be published there. Otherwise scope creep turns into a licensing incident.
If the client is close to needing capacity anyway, PPU can be an expensive detour, because the migration back costs full refreshes and rework. Model both.
Prices come from the Microsoft pricing page and the current licensing documentation. Quote the source, not a figure.

Recheck the PPU-versus-capacity feature table before repeating the limits — Microsoft revises it as capacity features move around