Fabric capacity licensing for Power BI

What it does

A capacity is a reserved pool of compute inside a tenant, sized in capacity units and bought as an F SKU. Workspaces are assigned to it, and the size of the SKU determines both how much compute the content gets and — above a threshold — whether people can view that content without a paid per-user licence.

Key facts

Microsoft's published F SKU range runs F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048 and F4096, with capacity units matching the number in the name. The Fabric trial capacity sits at 64 CUs.
Microsoft's own table maps F64 to the former P1, F128 to P2, F256 to P3, F512 to P4 and F1024 to P5, and maps the smaller F SKUs against the EM and A SKUs. Microsoft states this is a compute comparison and shouldn't be read as functional or licensing equivalence.
Microsoft is consolidating purchase options and retiring the Power BI Premium per-capacity P SKUs, and advises new and existing customers to consider F SKUs instead. P SKU references remain throughout the docs during the transition.
F64 is the free-viewer threshold. To view Power BI content on a free Fabric licence, the capacity must be F64 or larger and the user must hold the Viewer role on the workspace.
Capacity doesn't remove the authoring licence. Creating Power BI items in any workspace other than My workspace still requires Pro.
A and EM SKUs only support Power BI items. P SKUs support Fabric, but on a Power BI Premium capacity the Fabric items are off until an admin enables Fabric.
Every tenant has a shared capacity that hosts all My Workspaces plus workspaces using the Pro and PPU workspace types. New workspaces default there.
Any workspace, including a My Workspace, can be assigned to any capacity in the tenant once other capacities exist.
License mode has been renamed to workspace type. Terminology change only.
A tenant can hold as many capacities as it needs, and organisations commonly split them by geography or business unit.

When to use / skip

Capacity is the answer when the viewer population is large enough that per-user licences stop making sense, or when the workload genuinely needs the compute — big models, heavy refresh, Direct Lake, Fabric items. Below F64 you're buying performance and features, not licence relief, and that distinction has to be crystal clear before anyone signs anything.

The maths is straightforward and worth doing in front of the client: cost of an F64 against the cost of Pro for every viewer. Where the viewer count is in the low hundreds it's usually close; in the thousands it's not close at all. What tips it isn't just the number — it's whether those viewers would otherwise need Pro at all, and whether the workload would fit an F64's compute alongside serving them.

Configuration decisions

Whether F64 is reachable in this budget cycle. If it isn't, the design has to assume paid viewers and that changes the distribution model.
How many capacities, and how workspaces map to them. One capacity per business unit gives isolation and blame clarity; one shared capacity uses the compute better and produces worse arguments.
Whether the capacity is Power BI only or carries Fabric workloads too. Notebooks and pipelines competing with interactive report queries is a real sizing consideration.
Which workspaces move off shared capacity, remembering that semantic models have to move as well as reports for free viewing to work.
Whether autoscale or pause/resume behaviour is part of the cost model, and who owns the Azure resource that lets you do it.

Gotchas

Buying below F64 and expecting free viewing is the expensive mistake. F32 gives you compute; it gives you no licence relief at all.
The compute mapping table is a comparison, not an equivalence. Treating F64 as "the same as P1 in every respect" during a migration will catch you out.
Free viewers still need workspace roles or app access. Capacity is necessary, not sufficient.
Fabric items on a P SKU capacity need an admin to enable Fabric explicitly. The client assumes they bought it; the switch is off.
Capacity is shared compute with throttling behaviour. One badly built model can degrade every report on the capacity, and the first symptom is usually blame pointed at the wrong team.
Trial capacities behave like a paid capacity for sixty days and then don't. Don't build a go-live plan on one.

Consultant notes

Do the maths openly, with the client's own viewer counts, in the room. Licensing arguments settle much faster with a whiteboard than with a slide.
Where the client is close to F64, model the growth case. Buying just under the threshold and crossing it six months later is the worst of both outcomes.
Prices come from the Microsoft pricing pages and the current licensing documentation. Never quote a figure from memory, and never quote one that's more than a quarter old.
Flag the P-to-F transition explicitly in written recommendations. Existing P SKU customers need a migration conversation, and pointing at Microsoft's own retirement guidance keeps that conversation factual.
Capacity metrics monitoring should be part of the deal, not a follow-on. Sold capacity with no visibility of how hard it's being worked is a support ticket waiting to happen.

The P-to-F consolidation is still in flight — check Microsoft's current licensing guidance before restating any SKU mapping here