BI Capacity Limits: Power BI, Snowflake, Warehouses

Five percent. That's the number Microsoft's own documentation puts in writing: the share of your total user base that's actually hitting a Power BI report at any given moment, even at daily peak. Five percent.

So if I've got ten thousand people with the app, I'm really sizing for five hundred.

That's the assumption. And the entire capacity table is built on it. Microsoft published maximum user counts per SKU using that ratio. On an F64 or P1, a small paginated report workload, about a hundred rows, supports roughly two thousand five hundred users. Make it a large report, two hundred and fifty thousand rows, and the same capacity drops to one thousand three hundred.

Half. Just from the report getting fatter.

Half. Same hardware, same licence, same money.

Okay but here's my suspicion. Five percent sounds like a number that was true before everybody started scheduling morning refreshes and emailing dashboard links to the whole floor.

Hold that thought, because there's a second number in that same Microsoft doc that is much harder to argue with, and it's the one that actually takes people down. I'll get to it.

Fine. Set the scene for me. What does the failure actually look like on a Monday morning?

It looks like a finance semantic model refreshing at six a.m., users arriving at nine, and the Fabric capacity metrics app showing you hit eighty-five percent. Microsoft's own capacity planning guide uses almost exactly that example. And their sizing rule is brutally simple: take your peak thirty-second usage and make sure the SKU covers it. If your central finance dataset peaks around fifteen hundred capacity units per thirty seconds, F64 gives you one thousand nine hundred and twenty. F32 gives you nine sixty. You go F64.

And if you don't?

Throttling. Which is the polite word for everyone's report going slow at the same time, on the busiest morning of the month.

So just buy the bigger box.

Here's where it stops being a performance question and becomes a licensing question. F64 isn't just a size. It's a cliff. Microsoft's rule is that on F64 or larger, a user with only a Free licence and a Viewer role can read Power BI content. Below F64, every single person viewing needs Pro, PPU, or a trial.

Wait. So dropping from F64 to F32 to save compute money suddenly puts thousands of people on paid licences?

Pro is listed at fourteen dollars per user per month, paid yearly. Premium Per User is twenty-four. So yes. The cheaper capacity can be dramatically more expensive.

That is a genuinely nasty piece of pricing geometry.

And PPU has its own trap. Microsoft's guidance says PPU is more cost effective when you need Premium features for fewer than two hundred and fifty users. But PPU content needs PPU readers. A Pro licence will not open a PPU workspace. So the moment that report gets popular, every new reader costs you twenty-four dollars.

Okay, what's the number you were holding back?

Every workload on a capacity has a hard ceiling of five hundred concurrent report renders. Full stop. Microsoft's example: if you're rendering one hundred reports and you have two hundred export requests queued, you have two hundred renders left. Go past it and users get a Too Many Requests, four twenty-nine error.

So it's not degraded performance, it's a door slamming.

A door slamming. And exports are the killer, because Microsoft says pushing a big report out to Excel or PDF eats more resources than someone just paging through it. Which is exactly what finance teams do at close.

So where does Snowflake fit? Because the pitch there is always "it's elastic, stop worrying".

Snowflake's docs are refreshingly blunt about the trade-off. Too many queries at once and compute gets exhausted and queries queue. Your three options: make more warehouses and split the traffic, convert to a multi-cluster warehouse, or if you're already multi-cluster, raise the maximum cluster count. Multi-cluster requires Enterprise Edition.

And each of those costs money.

Each costs credits. And there's a subtlety people miss. Snowflake says increasing warehouse SIZE helps big complex queries, not small basic ones. Databricks makes the same distinction in their September twenty twenty-five guidance: resize when you see memory pressure and disk spills, add clusters when you see persistent queuing from many waiting queries.

Those are two completely different diseases with the same symptom.

Exactly the point. "Reports are slow" is not a diagnosis. And Databricks adds the line I'd tape to the wall: data volumes and number of users do NOT accurately estimate compute. Query types, patterns, and concurrency do.

Which brings me back to the five percent. Is that still real?

It's Microsoft's published planning assumption, and they caveat it hard. Those user numbers assume a capacity doing nothing else. No refreshes, no background jobs, no filtering or reshaping. Nobody has that capacity. So treat five percent as a floor, measure your own peak, and leave headroom.

And there's third-party pushback on the Microsoft side too, isn't there?

There is. AtScale ran a TPC-DS benchmark on Power BI Direct Lake and concluded it's fast on very small data but stumbles with larger data and higher user concurrency, and that a refresh causes a substantial cold cache hit. That's a vendor with a horse in the race, so read it as a claim, not a verdict. But the cold cache point is testable on your own tenant tomorrow.

So what's the actual decision rule?

Tier your workloads. Microsoft's guide says isolate mission-critical content on its own correctly sized capacity, turn on surge protection, and aim for peaks around seventy percent, not ninety-five. Then let the less important stuff share. You're not buying performance. You're buying headroom.

And next week? What are platform leaders watching?

Two things. Pull your Fabric capacity metrics app and find your real peak thirty-second CU number, not your average. Then count your readers and ask whether you're above or below the F64 line, because that one choice sets both your compute bill and your licence bill at once. Capacity isn't an infrastructure decision anymore. It's a pricing decision wearing an infrastructure costume.