Microsoft Fabric Licenses Explained - What You Actually Need and What You Probably Don't

Fabric licensing is the question I get asked about more than any other Power BI topic. Usually it comes up about a week after someone in finance looks at the Microsoft bill and asks why we're paying for three different things that all seem to do the same job. Fair question.

The licensing model isn't actually that complicated once you strip away the marketing. But Microsoft does themselves no favours with the naming and the constant rebadging. Power BI Premium used to be one thing. Then Fabric arrived and suddenly there are F-SKUs sitting next to P-SKUs, and the documentation refers to capacities and licenses interchangeably even though they aren't the same. I've spent enough billable hours untangling this for clients that I think it's worth writing it down properly.

This is the version of the conversation I have when someone calls and says "we got a quote, can you tell us if it makes sense".

The two-axis model

The first thing to understand is that Fabric licensing has two axes, not one. There's a per-user licence axis and a capacity axis. Most confusion comes from people treating these as either/or when they're actually both/and for anything beyond a small team.

The per-user side covers who can do what inside the product. Can this person build reports. Can they share content. Can they view a workspace.

The capacity side covers where the work runs. Compute power, refresh capacity, support for larger semantic models, premium features like deployment pipelines and the XMLA endpoint.

You need to think about both. A team of fifty business users can't just buy a single F64 and call it done, because the F-SKU gives them capacity but not the rights for individual users to author content. Conversely, buying everyone a PPU licence doesn't help if your semantic models are too big to fit inside PPU's memory limits.

Per-user licences

There are three per-user options worth knowing about.

Power BI Free is what you get with most Microsoft 365 plans. It lets someone use Power BI Desktop and publish to their own personal workspace. It doesn't let them share anything with anyone else. Useful for personal exploration, not useful for any actual business use case.

Power BI Pro is the standard licence for anyone who creates or consumes shared content. Around twelve Australian dollars per user per month at the time of writing. If a workspace is on shared (non-premium) capacity, every viewer needs Pro. That gets expensive fast in larger organisations.

Premium Per User (PPU) is around twenty-five Australian dollars per user per month. It unlocks the premium features (large models, paginated reports, advanced AI features, deployment pipelines) on a per-user basis. The catch is everyone who interacts with PPU content needs PPU too. There's no free ride for viewers. PPU is genuinely useful for small teams who need premium features but don't have the scale to justify capacity. Once you get past twenty or thirty users, the maths usually tips toward capacity.

Capacity SKUs

This is where it gets interesting. There are two families of capacity SKUs that do similar things with different commercial models.

P-SKUs are the older Power BI Premium capacities. P1 starts around five thousand Australian dollars a month and goes up from there. Monthly or annual commitment. These were the standard before Fabric arrived. Microsoft hasn't killed them off but they're not the path forward.

F-SKUs are the Fabric capacities. F2, F4, F8, all the way up to F2048. These can be bought pay-as-you-go through Azure (you can pause them when not needed) or as a reserved one-year capacity for a discount. F64 is the magic number because it's roughly equivalent to P1 and unlocks the same set of features, including the big one: viewers without Pro licences can consume content.

The pause capability of F-SKUs is genuinely useful and people underuse it. If your reports only matter during business hours, pausing the capacity overnight and on weekends cuts the bill substantially. We've helped a few clients set this up with Azure automation and the savings are real, not theoretical.

For a fresh deployment in 2026, I'd default to F-SKUs unless there's a specific reason not to. The flexibility is worth it and the per-hour billing maps more naturally to how organisations actually use the service.

The F64 inflection point

If you take one thing away from this post, take this. F64 (or equivalent P1) is the point where the licensing model changes shape entirely.

Below F64, every viewer of premium content still needs a Pro licence. So you're paying for capacity AND paying per user. The capacity doesn't help your licence bill, it just gives you more horsepower and premium features for the people already licensed.

At F64 and above, viewers don't need any individual licence. Anyone in your tenant can view content in that capacity for free (well, free in terms of additional licence cost, you're paying plenty for the capacity itself). This is the model that makes premium capacity viable for large user bases. Five thousand staff who just need to look at dashboards? F64 covers them.

Working out whether F64 is worth it is a straightforward calculation. Multiply your viewer count by the annual Pro cost. If that's more than the annual F64 cost, you're better off with the capacity. For most mid-sized Australian organisations, the break-even is somewhere around 350 to 400 viewers. We help clients model this properly when they're sizing up a Power BI consulting engagement.

Where dataflows and Fabric workloads fit

Fabric introduced a lot more than just renamed capacities. The same F-SKU that runs your Power BI workloads also runs Data Factory pipelines, OneLake storage, notebooks, real-time analytics, SQL warehouses, and the rest of the Fabric workloads. They all draw from the same capacity pool.

This is genuinely useful but it's also a trap. If your data engineering team runs a heavy Spark notebook job during business hours, your Power BI reports can slow down because they're competing for the same capacity units. We've debugged this for clients more than once. The fix usually involves either scheduling the heavy jobs off-peak or buying separate capacity for engineering workloads.

I'd recommend separating capacities by workload type if you have meaningful data engineering happening alongside reporting. The cost is higher but the operational headaches drop a lot. Our Microsoft Fabric consulting team typically advises this for any organisation running production analytics workloads.

The licensing gotchas worth knowing

A few specific things that catch people out.

Sharing content with external users. If you share a report with someone outside your tenant, they still need to be licensed. Either they bring their own Pro licence from their organisation (B2B guest scenario) or you can use the embed-for-external scenario which needs different licensing again. Plan for this if you have external partners.

Power BI Report Server. Comes bundled with Power BI Premium (per capacity) or as part of SQL Server Enterprise with Software Assurance. The on-premises option still exists for organisations that need it. Less common now, but worth knowing for regulated industries.

Auto-scale on Fabric. F-SKUs support auto-scale where the capacity bumps up if you exceed it. Useful for spikes, but it can rack up unexpected costs if you don't set sensible limits. Always set a max auto-scale ceiling.

Trial licences. The 60-day trial gives you PPU features. People build solutions during the trial and don't realise they need PPU or capacity to keep using them in production. Plan the licensing before the trial expires, not after.

What I'd recommend by org size

Rough guidance based on what we see across our consulting work.

Small team, under 10 active users. Pro licences for everyone who creates content. If you need premium features, PPU is fine for now.

Mid-sized, 10 to 200 users. PPU if you need premium features and the user count justifies it. Otherwise Pro plus a small F-SKU for engineering workloads if you have them. Look hard at whether you genuinely need premium features before paying for them.

Larger, 200+ users. F64 or higher. The viewer maths almost certainly works in favour of capacity. Make sure you have the data engineering capability to actually use the broader Fabric workloads, otherwise you're paying for features you won't touch.

Enterprise with mixed workloads. Multiple F-SKUs, separated by workload type. Production reporting on one, dev/test on another, data engineering on a third. Use pause schedules aggressively on non-production capacities.

Closing thoughts

The Fabric licensing model is broadly fair once you understand it. The pricing isn't cheap but it's predictable and there are genuine cost-control levers like pausing F-SKUs. The annoying part is the documentation, which still uses P-SKU language in some places and F-SKU language in others without making the relationship clear.

If you're sizing up a Fabric deployment and the licensing question feels murky, get someone to model it properly before you commit to a multi-year reservation. The differences between getting it right and getting it wrong can be tens of thousands of dollars a year. We do this kind of work as part of Power BI engagements all the time, and the licensing analysis usually takes a couple of days to do properly.

The official reference is at Microsoft's Fabric licensing docs if you want to read it for yourself. Worth a read, but bring a coffee.