BI Capacity

A BI capacity is a pool of compute and memory that a BI platform allocates to a set of content. Microsoft’s documentation defines it as “a distinct pool of resources,” where “the size of the capacity determines the amount of computation power available,” and workspaces “reside within capacities.” Everything in the pool competes for it. Product descriptions here follow the Microsoft Learn documentation, updated 2026-07-10 and checked in September 2026.

The term matters because a capacity is usually treated as a purchase — pick a size, pay the bill — when it is a design decision about who shares consequences with whom.

Refresh is what sizes it, not reading

The most useful fact in the documentation is about memory during refresh: the operation “causes the memory used by the semantic model to more than double, because in addition to the memory used by the refresh operation, the original copy of data remains available for active queries while another copy is being processed by the refresh.”

Query memory then stacks on top — it is “added to the memory needed to load the semantic model, and refresh it.” So a planning rule falls out: a model of size M needs more than 2M available, plus room for the queries running while it refreshes. Against the documented per-SKU ceilings — 25 GB maximum model memory on an F64, 100 GB on an F256 — a 20 GB model is fine at rest and can fail to refresh during business hours. The documentation is explicit that the ceiling is not usable in full, noting that “an amount of memory must be reserved for operations such as refreshes and queries.”

Scheduling has a matching trap. You “can schedule and run as many refreshes as required at any given time,” and the service runs them “at the time scheduled as a best effort” — subject to a model refresh parallelism limit per SKU. Best effort plus a parallelism cap means twenty models set to 06:00 do not all run at 06:00, and the last one finishes whenever. If a report carries a freshness commitment, the schedule has to be staggered by dependency rather than set to the hour everyone wants.

What happens at the limit

Exceeding the CPU a capacity provides does not fail one report; it degrades the pool — the capacity “throttles its interactive operations,” applied with “concurrency limits … per session.” Separate hard ceilings exist elsewhere, such as the documented 225-second limit after which visuals “time out and don’t display.”

Whether automatic relief is available depends on the SKU family, and this is worth checking rather than assuming. Autoscale triggers when interactive throttling starts and adds v-cores “every 30 seconds, until the number of v-cores you allocated for autoscale is reached,” each staying active “for a minimum of 24 hours” and billed to an Azure subscription. Its availability is stated explicitly: “Autoscale is available for Power BI Premium P SKUs. Autoscale isn’t available for Fabric F SKUs.” On an F capacity the responses are resizing, moving workloads, or reducing load — so a capacity plan that assumes automatic expansion needs to name which SKU it is planning for.

Two things follow for anyone diagnosing a slow dashboard. The symptom appears far from the cause — a finance month-end job can make a customer-facing report slow — so the first place to look is pool utilization rather than the report. And autoscale converts a performance problem into a cost problem silently, which is fine if someone is watching the bill and a surprise if nobody is.

Choosing the isolation unit

The real question a capacity poses is what shares it. One large pool is cheaper and lets any workload disturb any other. Separate pools cost more and contain the damage. This is the same trade as workload isolation anywhere else, and it should be settled from a stated requirement — “this dashboard responds within two seconds during business hours” — rather than after an incident.

Three practices make either choice workable.

• Separate what has a commitment from what does not. Content with a stated objective deserves a pool whose load you control; exploration and development can share.
• Watch headroom as a trend, not as an alert. Throttling arrives after weeks of visible drift. A monthly look at peak utilization catches it while resizing is still a planning decision.
• Attribute consumption to teams. A pool whose cost nobody owns gets optimized by whoever is asked, which is rarely whoever is spending — and the conversation about a heavy model goes nowhere without a number attached to it.

How capacity fits with model placement, refresh strategy, row-level security, and content ownership is worked through in The Dashboard Is Slow and Nobody Owns It.

References: Microsoft Learn, What is Power BI Premium? (documentation updated 2026-07-10); Microsoft Learn, Using Autoscale with Power BI Premium.