Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-fabric-capacity-and-f-skus.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn

What it does

A capacity is a pool of compute in your tenant that workspaces are assigned to. Its size, measured in capacity units, decides how much work can run and which features are switched on. F SKUs are the Azure-billed Fabric capacities; the older Power BI Premium P SKUs still exist but Microsoft is consolidating purchasing onto F.

Key facts

  • Microsoft states it is retiring the Power BI Premium per-capacity P SKUs and that new and existing customers should consider F SKUs instead. Both are still documented as of July 2026, so treat any client environment as potentially either.
  • The published F range is F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048 and F4096, with capacity units matching the number. Microsoft's own comparison table maps F64 to P1, F128 to P2, F256 to P3, F512 to P4 and F1024 to P5, but explicitly says this is a compute comparison, not a statement of functional or licensing equivalence.
  • F64 is the threshold that matters most in Power BI. At F64 or above, a user with a free Fabric licence and the Viewer role can view Power BI content. Below F64, every viewer needs Pro, PPU or an individual trial.
  • A and EM SKUs support Power BI items only, not the wider Fabric item set.
  • PPU is not a capacity. It gives one user most Premium features — 48 refreshes a day, models over 1 GB, the XMLA endpoint — but it doesn't let anyone create lakehouses, warehouses or notebooks. That needs an F capacity or a trial capacity.
  • Creating Power BI items outside My Workspace needs Pro or PPU regardless of what capacity is underneath.
  • Every workspace belongs to a capacity, and every capacity is tied to one Azure region and billed separately. Workspaces default to the tenant's shared capacity until you assign them.
  • P SKU capacities don't have Fabric items enabled by default. A Fabric admin has to turn Fabric on.
  • F SKUs can be paused and resumed from the Azure portal, by REST API, or on a schedule with an Azure runbook. Pausing stops billing and makes the content on that capacity unavailable. Resuming brings both back.
  • Pausing settles the accumulated smoothed usage and overage onto the bill, and immediately clears any throttling.
  • Pause and resume need specific Azure RBAC actions on the capacity resource — read, write, suspend and resume. Microsoft recommends a custom role scoped to those rather than a privileged built-in role.
  • The Fabric trial capacity behaves like F64 for viewing purposes and runs for 60 days.
  • "License mode" on a workspace is now called workspace type. Terminology only; behaviour unchanged.

When to use / skip

The question is almost never "do we need capacity" — it's "F64, or Pro licences for everyone". The crossover is arithmetic: count the read-only consumers, and if there are a few hundred of them, F64 usually wins and brings Fabric with it. Below that, Pro licences plus PPU for the handful of people who need Premium features is cleaner and easier to explain. Small F SKUs are a real option for Fabric workloads with a tiny Power BI audience, but be clear with the client that F2 through F32 don't remove the need for Pro licences to view reports.

Configuration decisions

  • Whether the estate runs one capacity or several. Separating dev from production, or a heavy data-engineering workload from the reporting workspaces, keeps one team's bad day off everyone else's.
  • Which region each capacity sits in, which is fixed at creation and drives data residency.
  • Whether non-production capacities are paused overnight and at weekends, and whether that's scripted through a runbook.
  • Whether the audience is licensed by Pro or carried by an F64-or-larger capacity.
  • If they're on a P SKU: whether and when to migrate to F, and whether Fabric gets enabled on the existing capacity in the meantime.

Gotchas

  • Pausing a capacity takes every report on it offline. There's no grace period and no warning to users, so scheduled pauses need to be genuinely outside working hours in every region the audience sits in.
  • The F-to-P mapping table is a compute comparison. Do not quote it to a client as "F64 is a P1" in a licensing conversation — Microsoft says in the same table that it isn't.
  • PPU workspaces are not capacity workspaces. This catches people out on external subscription recipients, on Fabric item creation, and on anything that says "Premium capacity" in the docs.
  • Fabric items on a P capacity need the Fabric switch turned on first. Clients on P sometimes conclude Fabric isn't available to them when it just isn't enabled.
  • Below F64, free users can't view Power BI content outside their own My Workspace. Buying a small F SKU to save on Pro licences doesn't work.
  • Detailed licensing terms live in Microsoft's licensing documentation rather than these pages. Where a client needs a contractual answer, send them there rather than reading it off a docs table.

Consultant notes

  • Say plainly that this area is mid-transition. P SKUs are being retired and F is the direction of travel, but plenty of live tenants are still on P. Position advice accordingly rather than pretending the question is settled.
  • Do the licence arithmetic with the client's own headcount in a spreadsheet, in front of them. It's the single most persuasive thing you can do in a capacity conversation and it stops the debate going in circles.
  • Pause and resume on non-production capacity is the easiest saving on the table and almost nobody has set it up. It's an afternoon of runbook work.
  • Flag the Azure RBAC angle early. Capacity is an Azure resource, so the people who can pause and resize it may not be the people who administer Power BI. That gap causes real delays during an incident.

Worth revisiting whenever the P-to-F transition moves on, or if the F64 threshold for free viewers changes.

Was this accurate?