Power BI and Fabric capacities: Understand the difference and cost structure

P-SKUs, A-SKUs, EM-SKUs and now we also have F-SKUs… all these different capacities that are out there today each have their own specifics. Lately, I’ve been in a lot of conversations around Fabric capacities. There seems to be some unclarity around what you pay for in the end and how it compares to Power BI Premium capacities. Therefore, I thought, maybe this is the right time to write it down – besides the Microsoft documentation that is already out there.

In this blog I will elaborate on differences in purchasing, billing and buying the capacities. I will not deep dive in capacity metrics or how capacity units are consumed.

Different capacity types

Let’s start with the difference between Power BI Premium capacities and Fabric capacities. The Premium capacities were introduced years ago, when Power BI Premium was launched. Premium capacities started at a pricepoint of ~4k a month in euros for a P1 capacity, bit depending on your contractual agreements with Microsoft. The Premium capacity was purchased as a license with a commitment for a year. So, doing the math you end up at ~48k in euros a year for a single P1 capacity.

With the launch of Microsoft Fabric, Microsoft introduced a new type of capacities. The Fabric cacity, aslo F-SKU. It has similar capabilities as P-SKUs, however they way how you purchase them and the options in scaling and pricing are significantly different. Microsoft moreless pushes all the users nowadays to F-SKUs, but before we go into comparisons, let’s introduce two more types of capacities.

At that point, we only talked about P-SKUs and F-SKUs, but not yet at the other two types of capacities that Power BI included. Embedded SKUs (EM) are also out there as well as Azure capacities – shortly A-SKUs. Both the A- and EM-SKUs are mainly used for Power BI embedded scenarios and are still valid options today. Although both P-SKU and F-SKUs also include embedding options.

SKUCapacity UnitsPower BI SKUPower BI v-cores
F220.25
F440.5
F88EM1 / A11
F1616EM2 / A22
F3232EM3 / A34
F6464P1 / A48
F128128P2 / A516
F256256P3 / A632
F512512P4 / A764
F10241024P5 / A8128
F20482048256
Table from official documentation.

As above table shows, the pricing point of all these capacities vary a lot! Where A- and EM-SKUs start at A1/EM1 size which is similar to an F8 in Fabric capacities. There is also a main difference in where you purchase a capacity. Below table helps you to understand the purchasing options in more detail.

Capacity typePurchase typeNote
A-SKUAzure subscriptionAzure capacity only supports Power BI workloads.
EM-SKUAzure subscriptionEmbedded capacity only supports Power BI workloads.
F-SKUAzure subscriptionFabric capacity supports both Power BI and Fabric workloads.
P-SKULicense portalPremium capacity supports both Power BI and Fabric workloads.

P-SKUs are deprecated starting July 1st – 2024 and can no longer be purchased.

All above options come as a per-capacity license. Leaving out the option for Power BI Pro and Premium per User (PPU) – which are user-based licenses. Depending on your use case, one capacity or another might fit better. For example, if you’re planning to use any of the Fabric workloads, the A- and EM-SKUs are already no option as they do not support Fabric workloads and are solely dedicated to the Power BI workload.

Besides the difference in workloads and purchase options, it must be noticed that Premium capacities can no longer be purchased starting July first 2024, as Microsoft announced mid-March 2024. If you find yourself using P-SKUs nowadays, you have to migrate to other types for capacities in the near future.

What do I pay for and how does billing work?

One of the most crucial things to understand is how the billing of capacities work. Let’s set aside the P-SKU given that one is deprecated and no longer relevant. All other capacities are purchased through Azure, for which you need an Azure subscription in order to purchase. Once the capacity is deployed, you will see it appearing in your Fabric admin portal – if you are the administrator of the capacity. By clicking the capacity, you can adjust settings and all. However, in some cases the capacity might be greyed-out. That is because all Fabric capacities can be paused.

Paused capacities cannot be used, nor the settings can’t be opened. Any workspace assigend to this capacity will show an error message stating that the items cannot be used at this point.

Understanding the concept of pausing capacities and what you exactly pay for, is important. Given for most Azure resources, you pay for what you use. Similar concepts are applied to the capacities. However, there is a slight difference. For many Azure resources, you pay for the consumption of compute during a run. For example, the duraction that a Logic App ran. With Fabric and Power BI capacities in Azure it works different though.

Let’s take an F8 capacity for example. F8 comes with 8 capacity units, which defines the compute we have available on this capacity. When I resume the capacity, at that point I start paying for the capacity. Even if the capacity is completely idle and not being used in any workspace at all. The fact that the 8 capacity units are available to my organization, means I have to pay for it. If I just leave it running 24/7, the F8 capacity will cost me roughly 1.2k euros a month. This is at a pay-as-you-go pricing model. I could obviously consider to pause my capacity outside of business hours to not pay for hte capacity whenever I’m not using it at all.

Pricing for pay-as-you-go capacities is by the second, with a minimum of one minute. So, in case I resume my capacity, I pay for at least 1 minute and after that I will pay by the second. But, in case I want to keep my capacity running 24/7, there are better options to consider. You can change to a Reserved Instanced (RI) which will also significantly drop your price with ~40%. With a reserved instance, you can still pause your capacity, however you will still pay for it – given you’ve reserved the capacity units.
Imagine you buy a F64 as reserved instance, you bought 64 capacity units as reserved instance. That does not necessarily mean you have to run an F64 capacity, but can very well be 2x F32, or 4x F16 etcetera. Basically, you reserve capacity units, not necessarily the capacity size.
Thanks to Andy Cutler and Koen Verbeeck for this addition.

Let’s look at some numbers to compare pricing for an F8 capacity:

CapacityPurchase typePrice per month
F8Pay-as-you-go€ 1.188,09
F81-year reserved instance€ 706,49
F83-year reserved instanceCannot be purchased yet
All prices based on Azure Pricing calculator, F8 capacity in West-Europe. Prices may differ based on regions.

Even with a reserved instance, I can still scale up my capacity if I want to. Let’s take another example. I still have the F8 capacity, but now as a reserved instance. That means I only pay just over 700 euro for the capacity. If I now just want to scale it up for 24 hours for example, as I need more compute at a month-end closure for example. It is not possible to just add an F2 to my workload, so from an F8, I directly have to scale up to an F16. Just for those 24 hours that I scale up, I pay an additional 78,12 euros. In this case, my capacity is split partly in the reserved instance for the first 8 capacity units, and the second pair of 8 capacity units is billed at pay-as-you-go pricing.

Let’s not forget the second part of princing when it comes to Fabric workloads. So far, we have discussed the pricing of the capacities which is used as compute. However, we left out of scope the OneLake storage pricing. This is the second component that needs to be added on top for any data you store in OneLake. Again, taking the West-Europe datacenter as example, the storage price is €0.0222 per GB. I personally think this is peanuts and will not directly affect any of your decision. However, it is something to keep in mind when you’re doing full loads in your solution every day, as the gigabites will add up quickly in that case.

Wrap-up

In short, we can forget about Power BI Premium capacities, they were purchased as a license with a commitment of at least a year. Nowadays, we have Fabric capacities which are way more flexible and also start at a lower price point. Therefore, it is definetely interesting to look at Fabric capacities when you are about to purchase a new capacity. In comparison to A- and EM-SKUs they serve a completely different usecase, given these capacity types only serve the Power BI workload in embedded scenarios.

Pricing of Fabric capacities is significantly higher, given the pay-as-you-go concept. Whilst this will also give you a lot of flexibility in return. When you’ve reached a stable situation, you can move to a reserved instance pricing, which drops your price by ~40%. It is also important to understand that you will pay for a running capacity. If you consume the purchased capacity units or not, does not affect pricing. You pay to reserve the capacity units for your organization.

Even with reserved instances, scaling up is still a valid option. Pay-as-you-go pricing is applied for any up-scaled capacity units. With this, a fair use case starts to exist to scale up at month-end closers for example or any other scenarion in which you temporarily need more compute.

A small disclaimer has to be added at the end. All prices listed in this blog are based on calculation on June 24th 2024 and solely cover the compute pricing. Total pricing for Fabric will also include a small amount of cost for OneLake storage. Also, prices may differ over Azure regions and currencies. For accurate pricing, I advise to use the Azure Pricing Calculator.

One thought on “Power BI and Fabric capacities: Understand the difference and cost structure

  1. Pingback: Explaining Power BI and Fabric Capacity Pricing – Curated SQL

Leave a comment