Power BI Licensing Decision Tree: Reference

Summary page: Decision Tree. Companion pages: Licensing reference, Pricing reference. Every cost comparison on this page points to section 5 of the pricing reference.

This page works out which licences you need, in five steps: count people once, identify requirements, find the eligible combinations, compare their incremental cost, then validate the capacity. Sections 4 to 6 explain what the published limits mean in practice. Every cost decision routes to the formulas in the pricing reference, and no fixed headcount decides a purchase.

Step one: count people once and record what they already hold

Every person is either a viewer or a publisher. Count each group once.

Then record, as attributes rather than as a third group:

• How many in each group already hold Microsoft 365 E5, Office 365 E5, Pro, or PPU. Those people cost nothing extra for Pro.
• Whether any publisher needs a Premium feature. The list is in step two.

Step two: identify requirements

Answer each of these before any product is named.

Step three: the tree

The tree ends in eligible combinations to be priced. Each leaf that says "compare" points to the formulas in the pricing reference, section 5.

Text version of the diagram. The first question is whether reports must stay on premises; if yes, the answer is Power BI Report Server, with rights through an F64 or larger reservation, existing Premium capacity, or SQL Server licensing. Otherwise, ask whether the reports are embedded in an application that authenticates to Power BI with its own identity; if yes, this is app-owns-data embedding on an F SKU, end users need no licence, human publishers need Pro, and the capacity is sized from active hours and load. Otherwise, ask whether the solution needs a lakehouse, warehouse, notebooks, pipelines, Copilot, or Multi-Geo; if yes, an F capacity is required, sized as the smallest SKU whose memory ceiling holds the measured peak of the largest model, with Pro per publisher and PPU ruled out for Multi-Geo. From there, if the sized SKU is below F64 and many viewers hold no licence, compare Pro per viewer against stepping up to F64 for free viewing; if the sized SKU is already F64 or larger, keep it and viewers are free with the Viewer role. If none of those apply, ask whether anyone other than the author views the reports. If not, and peak model memory is under 1 GB with eight or fewer refreshes a day and no Premium features, the Free licence in My workspace costs nothing; if any of those is exceeded, one PPU licence if peak memory is within 100 GB and there is no Multi-Geo, otherwise an F capacity sized to the peak. If others view the reports, ask whether any model exceeds 1 GB peak memory, more than eight refreshes a day, XMLA write, deployment pipelines, or the real-time DirectQuery partition. If not, the eligible options are Pro for unlicensed people, or F64 plus Pro per publisher when viewers are many; compare incremental cost and choose F64 only if it is cheaper and passes a load test. If any is exceeded, the measured peak memory of the largest model decides: under 25 GB, compare PPU for everyone touching the content against an F capacity whose ceiling holds the peak plus Pro per publisher; 25 to 100 GB, compare PPU against F128 (to 50 GB) or F256 (to 100 GB) plus Pro per publisher, with F64 not eligible; over 100 GB, an F capacity sized to the peak, with PPU not eligible, or reduce the model first.

Notes on the tree

Typical outcome. For most small and mid-sized organizations, the tree ends at the first compare node, and Pro is cheaper. A business with models under 1 GB and daily or twice-daily refresh needs Pro for the people who do not already hold E5, and nothing else.

Compare nodes. The pricing reference gives the break-even points at list price: F64 with Free viewers costs the same as about 357 Pro viewers in US East USD and about 405 in Canada Central CAD, with publishers' Pro costing the same on both sides. Existing E5 seats shrink the Pro side and move the break-even point higher. A capacity needed anyway for a model, Copilot, or Fabric workloads moves it lower. Then load-test: F64 has fixed compute and 600 viewers may need F128.

Paginated reports. They do not need Premium. Pro publishes them to shared workspaces. Free users author them and publish to My workspace.

Who needs PPU. Everyone who consumes content hosted in a PPU workspace, including reports elsewhere built on a PPU-hosted model, needs PPU. A PPU holder can still share ordinary Pro-workspace content with Pro users. So count everyone who will touch the Premium content.

Free viewing. Only F64 or larger, or an existing P capacity, makes viewers free. F2 through F32, A SKUs, and PPU do not. If the requirement is "500 staff read reports without 500 licences," the eligible answers are F64 or larger, or a P capacity you already hold.

Model size. In this tree, model size means measured peak memory. Microsoft states refresh can more than double a model's footprint while it runs, and queries add more. A capacity whose ceiling merely exceeds the resident size is a conditional candidate until peak memory is measured. Build the model, publish it, run a refresh under load, and read the peak before calling any SKU eligible.

F64 memory limit. Its ceiling is 25 GB. A model peaking at 40 GB needs PPU (100 GB), F128 (50 GB), or F256 (100 GB), whatever the viewer count says.

Multi-Geo. It rules out PPU because it is capacity-only, which is why the tree asks about it alongside Fabric workloads.

Single author. A solo author is not automatically on the Free licence. The Free licence in My workspace carries the same 1 GB and 8-refresh limits as Pro and none of the Premium features. One person needing twelve service refreshes a day needs PPU, and PPU itself is subject to its 100 GB ceiling and its Multi-Geo exclusion.

Testing capacity sizes. No SKU is eligible until measured. When a first capacity is only a conditional candidate, the next size up is also a candidate that needs its own validation. Microsoft reserves memory for refresh and query operations at every SKU, so each candidate needs its own measured peak and load test.

Fabric workloads above F64. If the workload already sized the capacity at F128, viewers are already Free with the Viewer role. "Step up to F64" applies only when the sized SKU is below F64.

Publishers. No capacity size removes Pro or PPU for a person publishing to a shared workspace. An application publishing through the REST API with a service principal is the only exception.

Copilot. Hosting on F2+ or P1+ unlocks it. So does assigning the user to a Fabric Copilot capacity, which lets Pro and PPU workspace users run Copilot. Pro or PPU alone does not.

Internal portals. These are usually user-owns-data. If the application passes each viewer's Entra token to Power BI, every viewer needs Pro or PPU unless the content is on F64+. Ask how the app authenticates; do not assume from the fact that a viewer sees a branded page.

The 1 GB model size limit

The limit applies to the compressed model in memory in the Power BI service; the source data is usually much larger. Power BI's columnar storage compresses well when columns repeat, so the same data can be a small fraction of its CSV size, or not, depending on what is in the columns. Row counts alone do not predict fit.

What makes a model more likely to fit. Star schema with a narrow fact table. Integers, dates, and low-cardinality codes. Unused columns removed. Detail aggregated to the grain the reports actually use.

What makes a model less likely to fit. Wide flat tables. GUIDs, free text, URLs, JSON, images. Millisecond timestamps. Calculated columns on large tables. Years of line-item detail kept when reports show monthly totals.

The examples below are illustrative candidates for Pro. None is a prediction. Confirm by building a representative model in Desktop, publishing it, and reading the compressed size and peak refresh memory before licensing.

Reducing model size. Before paying to raise the limit, check whether the model can be made smaller. Removing unused columns, summarizing detail, dropping high-cardinality keys nobody reports on, and correcting data types routinely halve a model.

The tiers above 1 GB. PPU allows 100 GB. Fabric capacity allows 3 GB at F2, 25 GB at F64, and 400 GB at F1024. All are memory upper bounds; refresh roughly doubles the footprint while it runs, so plan for the model plus headroom.

The 8 refreshes a day limit

Scheduled refresh pulls a fresh copy of imported data on a timetable. The limits are per semantic model: ten models can each refresh eight times a day on Pro.

The scheduler offers 30-minute slots. It targets a start within 15 minutes of each slot and may delay up to an hour under load. A schedule sets the earliest a refresh can start, and the actual start may be later. Eight evenly spaced slots means roughly three hours between refreshes and forty-eight means roughly thirty minutes, and neither counts as real time.

Workloads where eight per day is usually enough

• Monthly and weekly financial reporting. Data changes only when someone posts an entry.
• Sales pipeline and forecast dashboards refreshed a few times a day.
• Project profitability and utilization.
• Inventory reviewed at the start of a shift.
• Executive KPI dashboards reviewed daily or weekly.
• Help desk ticket volume trends, as distinct from live queue status.

Workloads where eight per day is usually not enough

• A dispatch or scheduling board that field staff act on.
• Live help desk queue status where an agent picks the next ticket from the dashboard.
• Production line or machine status.
• Same-day order fulfilment during a peak period.

Alternatives to buying more refreshes

DirectQuery. The report queries the source live. It imports nothing, so no refresh limit applies, and it works on Pro. The cost is report speed and load on the source database. For a small operational dashboard over SQL Server this is often the right answer.

Automated refreshes. A refresh triggered by Power Automate or the REST API on shared capacity counts as one of the eight. It becomes uncapped only on PPU or capacity.

How fresh the data needs to be. Ask what someone would do differently if the number were 15 minutes old instead of 3 hours old. If nobody would act differently, eight per day is enough, and a genuine need for fresher data points to DirectQuery, Direct Lake, or streaming.

The 10 GB storage limit

Pro gives 10 GB of published storage per licensed user, pooled across the tenant. Ten Pro licences is a 100 GB pool. A published report with its model typically occupies 20 MB to 300 MB.

Most organizations never reach this limit. The 1 GB per-model cap is hit long before the pool runs out. Watch it only if you keep many near-1 GB models, historical snapshots, or heavy dataflows. Confirm actual usage in the admin portal. PPU and capacity raise the pool to 100 TB.

Sizing a Fabric capacity

Capacity Units measure compute only. Microsoft does not publish a users-per-SKU table because consumption depends on model size, query complexity, refresh volume, and how many people are active at the same moment.

Sizing steps.

1. Start a 60-day Fabric trial (F4 or F64 equivalent; eligible admins can upsize to 64 CU), or start on F2 pay-as-you-go.
2. Install the Microsoft Fabric Capacity Metrics app.
3. Run the real workload for two to four weeks.
4. Read actual CU consumption and size from that. Use the Fabric SKU Estimator for growth.

What the SKU size does fix is the maximum memory for a single semantic model: 3 GB at F2, 25 GB at F64, 400 GB at F1024. If you have one large model, that sets the floor regardless of user count.

Pausing and resizing. A pay-as-you-go F capacity paused overnight and on weekends bills roughly 30% of the always-on figure. A reservation bills for its term regardless. Downsizing below F64 removes Free viewing for that period. Copilot usage consumes the capacity that bills it, so watch the metrics app if Copilot is enabled on a small SKU.

Moving from Premium P SKUs

Microsoft no longer sells P SKUs. Each existing P subscription retires at the end of its current agreement term. Customers on an active Enterprise Agreement can renew annually until the EA ends. After expiry: 30 days grace, throttled from day 31, all operations rejected from day 91.

Map P1 to F64, P2 to F128, P3 to F256, P4 to F512, P5 to F1024 as the starting point, then right-size with the Capacity Metrics app. Buy the F SKU first, reassign and validate workspaces, then cancel the P SKU. If you use Report Server, verify the F64+ reservation or SQL Server entitlement before cancelling.

Worked examples

Thirteen situations, each with the recommendation, the reasoning, the cost at Canadian list prices, and what is checked before purchase, are in Worked Examples. The letter codes there (A to M) match the paths through the tree above.

Discovery

The questions to ask in the first meeting

1. How many people will view reports? Count everyone.
2. How many people will publish reports?
3. How many of each already hold Microsoft 365 E5, Office 365 E5, Pro, or PPU?
4. Where does the data come from, and how much of it is there? Ask for a row count and column list on the largest table.
5. How fresh does the data need to be, and what decision depends on that freshness?
6. Will reports be shown to people outside the organization? If through an application, does the application sign in to Power BI as itself or as each viewer?
7. Is there any appetite for Copilot or for data engineering beyond Power BI?
8. Must anything stay on premises?

Questions 1, 3, and 5 settle most small-business cases. We complete a fuller worksheet before any quote, covering the measured size of the largest dataset, peak viewer numbers, data-residency needs, and growth over the next one to three years.

Sources

• Understand Microsoft Fabric licenses and capacity
• Power BI service features by license type
• Power BI Premium Per User
• What is Power BI Premium
• Data refresh in Power BI
• Configure scheduled refresh
• Paginated reports FAQ
• Data reduction techniques for Import modeling
• Capacity and SKUs in embedded analytics
• Fabric capacity planning
• P SKU migration decision guide
• Copilot for Power BI overview
• Fabric Copilot capacity
• Power BI Report Server