Power BI Premium vs Fabric: how to choose and right-size your capacity

Power BI Premium vs Fabric stopped being a purchasing decision and turned into a migration deadline. Microsoft retires Power BI Premium per capacity SKUs at the end of each customer's current agreement term, no longer sells new P SKUs, and no longer allows customers with expiring Enterprise Agreements or Microsoft Cloud Agreements to add or renew that capacity. What remains open for most business intelligence teams is which F SKU to land on, and how to size it.

The timeline leaves little room for improvisation. After a P SKU subscription ends, content stays accessible for a 30 day grace period at the current capacity size. From day 31, interactive operations get delayed. From day 91 onward, every operation is rejected, and the data remains retained yet unreachable until the workspaces move to an F SKU capacity. Treating that window as a migration plan turns a licensing change into an outage, so sequence deserves the same attention as the governance model around the reports.

Two decisions carry most of the risk. The first is which F SKU size to land on, because the equivalence table is a starting point and never an answer. The second is how Fabric meters compute, since bursting, smoothing and throttling behave differently from the fixed v-core model teams learned on Premium. Consumption data resolves both, which keeps a Fabric migration predictable.

Power BI Premium vs Fabric: what actually changes

Moving from a P SKU to an F SKU changes where the capacity is bought and how it is billed. P SKUs came from the Microsoft 365 admin center on a monthly or yearly commitment. F SKUs are Azure resources: pay as you go by default, billed per second with a one minute minimum, with optional reservations for a discount, and priced regionally instead of globally. Cost tracking moves with them into Microsoft Cost Management and Azure Monitor, beside the rest of the Azure estate.

Autoscale is the line that surprises most admins. On Premium it added v-cores billed per 24 hour period whenever the capacity ran hot, turning overload into a billing event instead of a user-facing one. F SKUs have no equivalent, replacing it with manual or scripted resizing through the Azure portal, capacity overage protection and the option to pause. Anyone who leaned on autoscale as a silent safety net needs an explicit routine, in the same spirit that cloud cost control replaces hunches with measurement.

Per user licensing survives untouched. Pro and Premium Per User stay active, since the retirement covers per capacity SKUs P1 through P5 only. On F64 and larger, a Fabric Free license plus the Viewer role still opens a report as it did on Premium. Power BI Embedded now ships with every F SKU, removing the separate EM or A SKU that embedded setups carried and taking one variable out of any BI platform comparison.

How to choose the right F SKU

Mapping is the easy part. Each P SKU v-core corresponds to 8 capacity units, so the equivalence follows arithmetic, and Microsoft's migration decision guide publishes the table. Compute equivalence stops short of functional and licensing equivalence, so the mapping works as a floor to start from before adjusting with measured data from the reporting estate.

One threshold matters more than the compute numbers. F64 is where free viewer access begins, so a Fabric Free license with the Viewer role opens a report there, while every SKU from F2 to F32 requires Pro or PPU for each person who merely looks at a dashboard. Authors and editors always need Pro or PPU regardless of size. An operation with hundreds of read only consumers can therefore pay more on a smaller capacity once those per user licenses are counted, which is the arithmetic behind licensing cost optimization.

Right-sizing then follows a short routine, and the order helps as much as the modeling work that feeds the capacity:

• Review current utilization in the Capacity Metrics app pointed at the existing P SKU, covering the maximum period it retains, roughly 30 to 45 days, autoscale consumption included.
• Identify sustained peaks where CU utilization sits near 100% for long stretches, since that pattern argues for the equivalent SKU or a larger one.
• Identify low utilization windows, because a capacity idle most of the day can drop a size and use pause and resume to cover the gap.
• Factor in workload growth from the Fabric items planned after the move, such as lakehouses, warehouses, notebooks and pipelines.
• Complement history with the Fabric SKU Estimator, which models forward looking consumption from a workload profile.

Cost by scenario

Absolute prices belong in Microsoft's own rate card, since every F SKU is priced per region and billed per second. What generalizes is the cost shape: capacity size, the per user licenses stacked on top, and the levers available to cut the bill in a given BI environment.

Current rates per SKU, pay-as-you-go and reservation, by region and currency: Microsoft Fabric pricing.

Two lines carry most of the savings. Reservations discount a capacity that runs continuously, while pause and resume pays off only where idle windows are real, so combining both on one SKU rarely makes sense. Power BI Report Server adds a condition, since it now requires a Fabric reservation of F64 or higher, worth checking before cancelling anything in the existing estate.

Region choice defaults to the same Azure region as the current capacity. A same region reassignment of standard Power BI items runs with effectively no downtime beyond interrupted refreshes, while a cross region move deletes large storage format semantic models and every Fabric item, which then have to be recreated. Microsoft advises against chasing regional price differences for that reason, since prices shift and rebuilding lakehouse and warehouse items outweighs the saving.

Sequence protects the users. Buy the F SKU first, reassign workspaces, validate refreshes and reports, then cancel the P SKU once the new capacity carries production. Splitting a capacity already near 100% utilization creates overloads instead of savings, the same trap seen in shared modeling environments.

How to right-size a Fabric capacity without triggering throttling

Capacity units get measured in 30 second timepoints, and Microsoft's capacity planning documentation reduces that to a multiplication: an F64 provides 64 CUs per second, so 1,920 CUs in every timepoint, and 2,880 timepoints fill 24 hours. The Capacity Metrics app evaluates on that same cycle, so its numbers are the ones charged against the data platform.

Two mechanisms keep short spikes from becoming incidents. Bursting lets an operation temporarily consume more compute than the SKU provides, so a heavy query finishes quickly even on a modest capacity. Smoothing then spreads that consumption forward, averaging interactive operations over a minimum of five minutes and up to 64 minutes depending on how much they consumed, and background operations over 24 hours. A nightly pipeline therefore contributes a thin slice to thousands of timepoints instead of one spike, so scheduled refreshes rarely need staggering in a well sized data environment.

Throttling starts only when smoothed usage exhausts future capacity, and the Fabric throttling documentation defines the stages by how far ahead the capacity has already borrowed. The stages arrive progressively so refreshes keep running while interactive traffic absorbs the first pressure, as a mature analytics operation protects its critical jobs first.

Utilization above 100% in the metrics app does not automatically mean throttling. The Utilization chart shows overages, the Throttling chart shows when smoothed usage crossed one of those limits, and the System events table records throttling history with minutes to burndown. Reading only the first chart produces panicked resizing, while reading all three separates a real bottleneck from noise, the discipline that also keeps dashboards useful for decisions.

Capacities are self-healing, so unused timepoints burn down the carryforward on their own, and three levers speed that up when a reporting environment cannot wait:

• Temporarily scale up the SKU, so each timepoint carries more idle capacity and the carryforward clears faster.
• Pause and resume the capacity, which sums accumulated overages and smoothed operations into the Azure bill, then restarts with zero future capacity consumed.
• Enable capacity overage billing, keeping in mind that the extra compute costs three times the normal capacity rate.

F SKUs also bring usage governance that Premium never offered, including workspace surge protection, capacity surge protection and a mission critical designation. Those controls decide which workloads absorb the pressure when a shared capacity runs hot, turning sizing into a governance conversation as much as a financial one, much like defining ownership in a decentralized data model.

The retirement timeline has largely made this decision, so the real work sits in sizing and operating the capacity you land on. Baseline 30 to 45 days of consumption before buying, respect the F64 threshold where viewer licensing changes shape, and build the resize and pause routine that stands in for autoscale. BIX Tech works across multiple data, cloud and analytics platforms, and the right capacity size shifts with refresh windows, concurrency and licensing mix.

If your company is planning the move from Power BI Premium to Microsoft Fabric capacity and wants to size it on evidence instead of a mapping table, our specialists can help you baseline consumption and design the right architecture for your context. Talk to our team and move forward with your data maturity. ⬇️

FAQ: Power BI Premium vs Fabric

What is the difference between Power BI Premium and Fabric capacity? Power BI Premium per capacity SKUs are bought as a Microsoft 365 commitment with a fixed size and optional autoscale. Fabric F SKUs are Azure resources billed pay as you go or by reservation, priced by region, and they support on demand resizing plus pause and resume. Microsoft is retiring the P SKUs at the end of each agreement term.

Which Fabric F SKU replaces a P1 capacity? F64 replaces P1, because each P SKU v-core corresponds to 8 capacity units. The full mapping runs P1 to F64, P2 to F128, P3 to F256, P4 to F512 and P5 to F1024. Treat the match as a starting point, then right-size using 30 to 45 days of consumption data from the Fabric Capacity Metrics app.

Do report viewers still need a Power BI Pro license after migrating to Fabric? It depends on capacity size. On F64 and larger, users with a Fabric Free license and the Viewer role can view content, the same behavior as on P SKUs. On F2 through F32, every viewer needs Pro or Premium Per User. Authors and editors always need Pro or PPU, regardless of the SKU.

How do you right-size a Microsoft Fabric capacity? Start from the equivalent F SKU, then review the Capacity Metrics app for sustained peaks near 100% CU utilization and for long idle windows. Sustained peaks point to the same size or larger, while long idle periods allow a smaller SKU with pause and resume. Add headroom for new Fabric workloads such as lakehouses, warehouses and pipelines.

What happens if a Power BI Premium subscription ends before migrating? Content stays accessible for a 30 day grace period at the current capacity size. From day 31 to day 90, access is throttled and interactive operations are delayed, though export and recovery still work. From day 91, all operations are rejected and the data stays retained but inaccessible until the workspaces move to an F SKU capacity.