Power BI Pro, PPU or Fabric Capacity?

The shortest useful answer

Use Power BI Pro when authors and viewers collaborate in normal shared-capacity workspaces and every consumer can be individually licensed.

• Use Premium Per User (PPU) when a relatively small, defined group needs Premium Power BI features and every person accessing a PPU workspace can hold PPU.
• Use Fabric capacity when the organisation needs Fabric workloads, elastic capacity, or broad distribution. Free users can view Power BI content only when the workspace is on F64 or larger and they have the Viewer role.
• Paginated reports no longer decide the question by themselves: Microsoft documents the same basic licence requirements for .rdl
• and .pbix publication. Pro users can publish paginated reports to ordinary workspaces, subject to feature and export limits.

Power BI Pro: licence the collaboration population

Pro lets a user publish, share, collaborate, and consume content shared by other Pro users in standard Power BI workspaces. It is often the cleanest option for 110 internal users when all 110 need interactive access and the models fit shared-capacity limits. Do not calculate only the 10 report developers. In a Pro workspace, the 100 consumers also need Pro or another qualifying entitlement such as the Power BI Pro service plan included in Microsoft 365 E5. Pro is not “developer only,” and free users cannot consume private shared-capacity content simply because they never edit it.

Premium Per User: Premium capability with a membership boundary

PPU includes Pro capabilities plus most Premium Power BI features on a per-user basis. It does not create Fabric capacity for lakehouses, warehouses, or notebooks.

• The access rule is strict: content in a PPU workspace can be shared only with other PPU users, unless the content is moved to a qualifying capacity. If 10 authors and 100 viewers need the PPU workspace, plan 110 PPU licences.
• PPU can be attractive for a small advanced analytics team. It becomes less attractive when a large audience only needs to read reports.
• PPU also has API and distribution limits. For example, Microsoft documents paginated-report export API limits and states that subscription capabilities with
• different data views for recipients require capacity. Validate automation and external delivery instead of assuming every “Premium” feature is identical.

Fabric capacity: buy compute, then check viewer rights

Fabric F SKUs provide capacity units for Power BI and other Fabric workloads. They can be purchased through Azure, scaled, and paused. That flexibility introduces capacity management, throttling, reservation, and monitoring decisions that do not exist in the same form with per-user licences. The threshold that causes most confusion is F64. On F2 through F32, internal viewers of Power BI content still need Pro, PPU, or a suitable individual trial. On F64 or larger, users with a Fabric Free licence can view Power BI content in a capacity workspace when assigned the Viewer role or given appropriate app access. Authors still need Pro or PPU to create and publish Power BI items in shared workspaces. F64 is therefore not a generic recommendation. It is the first F SKU that changes the internal free-viewer equation.

What happened to Power BI Premium P SKUs

Microsoft is retiring Power BI Premium per-capacity P SKUs. New P SKUs are no longer sold, and each

• existing subscription ends at the end of its applicable agreement term. The migration path is Fabric F capacity.
• Microsoft documents a post-expiry safety sequence: 30 days of grace, throttled access from days 31–90, and rejected operations from day
• 91 until workspaces are moved or the capacity is addressed. This is a recovery window, not a migration plan.
• F64 maps broadly to the former P1 scale in Microsoft’s capacity table, but do not size by

Practical checks

label alone. Use actual Capacity Metrics, refresh peaks, query concurrency, background workloads, model sizes, and growth.

The 10-author, 100-viewer example

Licence all 110 users with Pro, accounting for

• any Pro entitlement already included in Microsoft
• 365 E5. This is usually simpler than
• buying F64 solely to avoid viewer licences.
• buying F64 solely to avoid viewer licences.

Scenario A: ordinary dashboards, models under shared limits

Licence all 110 users with Pro, accounting for any Pro entitlement already included in Microsoft 365 E5. This is usually simpler than buying F64 solely to avoid viewer licences. Scenario B: Premium Power BI features for the same 110 people Compare 110 PPU licences against an appropriately sized Fabric capacity plus the 10 author licences. Include administration and compute headroom, not only licence list price. Scenario C: 10 authors, thousands of read-only viewers F64 or larger can change the economics because free users can consume the capacity-hosted Power BI content. Validate concurrency and workload size; a viewer count alone does not size compute. Scenario D: data engineering in Fabric, but F16 is enough An F16 may run the Fabric workload, but it does not grant free viewing of Power BI reports. Viewers still need Pro or PPU. Buying some Fabric compute does not automatically replace Power BI user licences. Scenario E: external customers External sharing and embedded “app owns data” have different identity, capacity, security, and licensing models. Do not apply the internal F64 free-viewer rule to a customer-facing application without an embedded architecture review.

Paginated reports: the detail behind the argument

Microsoft’s current documentation says paginated .rdl reports use the

• same licence requirements as Power BI .pbix reports.
• A Pro or PPU user can publish them to another workspace with the required workspace role.
• The remaining design questions are model limits, scheduling, subscriptions,
• export API volume, recipient licensing, and delivery outside the

Practical checks

tenant. “We need paginated reports” is no longer enough to jump directly to PPU or Fabric capacity.

Build the comparison with real usage

Collect: count of authors, contributors, and viewers;

• licences already included in Microsoft 365 suites; workspace types and roles;
• model size and refresh memory; refresh frequency and concurrency;
• paginated subscriptions and export automation; Fabric workloads beyond Power BI;
• internal, guest, and external audiences; uptime, pause, region, and reservation requirements;

Practical checks

P SKU expiry date, if applicable. Then model at least three options. Axeti can help combine the licence inventory and Fabric capacity telemetry so the decision is based on the actual workload rather than an F64 rule of thumb.

Sources and scope: Microsoft Learn, Power BI service features by licence type: Free, Pro, PPU, and capacity access rules. Microsoft Learn, Understand Microsoft Fabric licences: F SKU scale, F64 threshold, author and viewer requirements. Microsoft Learn, Power BI Premium to Microsoft Fabric migration overview: P SKU retirement and migration. Microsoft Learn, P SKU to F SKU migration decision guide: agreement timing and post-expiry stages. Microsoft Learn, Get started with paginated reports in the Power BI service: current .rdl licence requirements. Prices, reservations, Azure regions, workload limits, and included Microsoft 365 service plans change. Validate the tenant and run measured capacity tests before committing.