This is the 7th part of our Fabric Capacity Management series. If you haven’t yet, check out the earlier articles:
- Part 1: Causes and Consequences of Capacity Overloads
- Part 2: Actions to Take During Capacity Throttling
- Part 3: Alerting Users During Capacity Throttling
- Part 4: Capacity Monitoring for Self-Service
- Part 5: Capacity Monitoring for Self-Service
- Part 6: Development vs. Production
As we explained in the previous article, Microsoft Fabric is a capacity-driven model. This means you purchase a certain amount of resources and pay for them — whether you use them fully or not. Ideally, we’d want to reach close to 100% utilization, but in reality, that rarely happens.
Why? Because on a Fabric capacity there are two types of operations:
- Background operations – smoothed over 24 hours
- Interactive operations – smoothed over 5 minutes (sometimes up to 64 minutes)
In the Microsoft Fabric Capacity Metrics, the picture often looks like this:
You’ll typically see a relatively stable baseline from background operations, with spikes from interactive operations layered on top. The volume of interactive activity varies heavily – during working hours, it’s naturally higher; outside business hours or on weekends, it’s much lower. As a result, we’re often paying for unused capacity.
The height of those spikes also varies. It depends not only on how many users interact with reports but also on how optimized the reports and queries are. Poorly designed queries – for example, ones loading massive datasets or using inefficient DAX – can easily consume 10%, 20%, or even 50% of a capacity’s limit in a single spike. These peaks can quickly lead to throttling. Because of this, we need to keep some resources in reserve to absorb spikes and pay off CU debt quickly.
Assigning Workspaces to Capacities
Understanding how utilization works brings us to the next challenge: how to assign workspaces across capacities.
In some organizations, cost allocation is the main driver. Each capacity hosts workspaces that are tied to a particular unit (e.g., a region) simply because costs are easier to allocate that way. The downside is that this creates inefficiencies: one region might be constantly overloaded while another capacity sits half-empty. That’s why it’s important to have proper cost-management practices in place — ideally allocating costs based on actual usage at the workspace level. This flexibility makes smarter workspace assignment possible.
Regional Considerations
Another factor is region. Currently, moving workspaces across capacities in different regions is limited, especially when they contain dataflows, datamarts, or Fabric items. Cross-region migration can create issues, so it’s usually best to minimize the number of regions (ideally one or two). While this might slightly increase latency for some users, the benefit of having elasticity in workspace assignment outweighs the drawback. Otherwise, you risk creating regional silos where workspaces can’t move freely.
Stable vs. Unstable Workspaces
So how do you decide where to place workspaces? The answer is: it depends. For some organizations, throttling starts when background usage passes 30%; for others, the threshold might be 60% or even 80–90%. It all depends on how stable the background operations are and how large interaction spikes can get.
To maximize utilization, we’d ideally separate stable workloads from volatile ones. For example:
- Capacity A – hosts workspaces with stable background operations and low volatility. Here we can safely drive up background usage close to the limit.
- Capacity B – hosts workspaces with less predictable usage and higher spikes. This capacity can keep more resources free to absorb sudden load and stabilize quickly.
One way to achieve this is by splitting transformation and consumption:
- Transformation workspaces (dataflows, lakehouses, warehouses, notebooks) go to Capacity A.
- Consumption workspaces (semantic models and reports) go to Capacity B.
Even if you don’t separate them strictly, categorizing workspaces based on size and stability is valuable. With proper auditing (something we’ll cover in future posts), you can identify which workspaces are stable, which are heavy but predictable, and which are the most volatile. Assigning them strategically across capacities helps you minimize throttling while making the best use of your resources.
In the Capacity Metrics, it could look like this:
Final Thoughts
Smart workspace assignment is about elasticity – having the ability to balance stable and volatile workloads across capacities, rather than locking into rigid silos.
How does your organization approach this? Do you have a strategy for distributing workspaces across capacities, or is it handled ad hoc?
#MicrosoftFabric #PowerBI #Optimization #MicrosoftFabricOptimization #SelfService #SelfServiceBI #CitizenDeveloper #FabricMonitoring #FabricObservability #FabricManagement #FabricGovernance
Leave a Reply