Fabric licensing looks complicated, so people buy big and leave it running. It comes down to two ways to pay and one threshold that flips the maths.

Per-user or capacity? The one threshold that decides

Microsoft Fabric licensing looks complicated, and when something looks complicated the safe-feeling choice is to buy big and leave it running. That instinct is the single most expensive mistake mid-market organisations make on the platform. They reserve a large capacity to feel safe, run it around the clock, and pay every month for headroom they never touch.

We have written more on this via our Microsoft Fabric delivery, and Stop Paying For Fabric Capacity You Do Not Use takes a closer look at a related part of the picture.

It is not actually hard once you separate the two ways of paying for it and understand the one threshold that changes the maths. Prices and exact tiers move, so treat the specifics as shape rather than gospel, and confirm current figures with Microsoft before you commit.

Two ways to pay

Per-user licences, Power BI Pro and Premium Per User, are attached to people. You pay for each person who needs them, and with Pro that usually means both the people who build content and the people who consume it. For a small team that mostly builds and shares among itself, per-user is often the cheapest and simplest option, and there is nothing to size or manage.

Capacity, sold as Fabric F-SKUs from small to large, is a pool of reserved compute. You pay for it whether anyone uses it or not, but in return it covers the heavy work, data engineering, pipelines, lakehouses, warehousing, as well as reporting. Capacity is a decision about workload and reach, not headcount, and that is the distinction most over-buying ignores.

The threshold that flips the decision

There is one rule worth understanding because it changes the answer. Above a certain capacity size, report consumers can view content without their own per-user licence. Below it, every viewer needs one. So for a reporting-heavy organisation the real question is simple arithmetic: does the cost of that larger capacity come in under the cost of per-user licences for all your viewers? With a large viewer audience it often does. With a small one it does not, and the capacity is mostly an empty pool you are heating for no one.

That gives a clean rule of thumb. Capacity earns its keep in two situations: when you are doing genuine data engineering, a lakehouse or warehouse and pipelines rather than just reports; or when you are putting reports in front of an audience large enough that per-user licences for all of them would cost more than the capacity. If you are a small team building reports for each other, capacity is usually money spent on compute you do not use.

Right-size, and pause

Two habits do the rest. Start smaller than feels comfortable and buy for the workload you have, not the one you imagine; moving up a tier takes minutes and you will have real usage to justify it, whereas starting large just means paying for emptiness in the meantime. And pause what is not in use. A development or test capacity left running overnight and at weekends is burning roughly two-thirds of its cost producing nothing, because most of the week is outside working hours. Pausing is built in and can be scheduled, and nobody notices the difference because nothing was running at 2am anyway. Only consider a reserved, committed price once your usage has settled, because committing early to the wrong size just locks in the mistake.

The sum worth doing this week

So run one calculation. Count your report viewers, price per-user licences for all of them, and compare that against the capacity tier that would let them view without a licence. Whichever side of the line you land on is your answer, and a fair number of organisations are sitting on the wrong side of it purely out of habit. Getting this right, and revisiting it as you grow, is part of every Microsoft Fabric and data platform engagement we run, and the full breakdown, including the traps, is in our Fabric Licensing, Decoded guide.

If any of this sounds familiar, talk to us about your data.

Related reading

• You Probably Do Not Need Microsoft Fabric Yet
• You Do Not Need Real-Time Data. You Need Right-Time.
• Getting your Business Central data into Power BI: the options