Fabric Capacity, Part 3: When Several Teams Share One Capacity (Part 3 of a 3-part Series)

The Executive Insight

Parts 1 and 2 treated the capacity as one thing with one workload. Most real estates aren’t that tidy. Sales, Operations, and Finance all land on the same F-SKU, and the meter stops being a single team’s problem and becomes a shared one.

This changes the question. It’s no longer “how much are we consuming,” it’s “whose workload is consuming it, and what happens to everyone else when one team spikes.” Those are mechanical questions with mechanical answers, and getting them right is the difference between a shared capacity that runs smoothly and one where every team blames the platform for a slowdown that another team caused.

Issue #22 closes the arc. Part 1 was the mental model, Part 2 was sizing, and this one is what happens when the pool has more than one team drinking from it.

One Pool, Many Teams

The first thing to internalize: workspaces are assigned to a capacity, and every workspace on that capacity draws from the same CU pool. There is no per-team partition inside a single capacity. Finance’s month-end refresh and Operations’ Spark job aren’t running in separate lanes; they’re spending from one shared budget at the same time.

Smoothing pools across all of it. A background job from one team smooths over 24 hours into the same timeline that every other team’s work is being measured against. So a heavy overnight load in one workspace doesn’t stay contained to that workspace’s “share.” It raises the consumption baseline the whole capacity is operating against the next day. This is why a team that did nothing unusual can find the capacity running hot: someone else’s smoothed activity is still being paid down.

Noisy Neighbors and How Throttling Spreads

Here’s the consequence that surprises teams most. Throttling is applied at the capacity level, not the workspace level. Microsoft’s own documentation is explicit: when a capacity is overloaded, that whole capacity experiences reduced performance, while other capacities keep running normally.

In plain terms: if one team overspends the shared budget badly enough to trigger throttling, every team on that capacity gets throttled, not just the one that caused it. The interactive delays and rejections from Part 1 hit the innocent workspaces too. One team’s runaway notebook becomes everyone’s slow morning.

There’s one extra wrinkle worth knowing if you split data across capacities. When an artifact lives in one capacity but is consumed from another (a OneLake shortcut into another capacity’s data, for instance), it’s the consuming capacity’s throttling state that governs whether the call is throttled. So the blast radius of a hot capacity follows consumption patterns, not just workspace assignment.

Showback: Seeing Who Actually Consumed It

The good news is that “who’s spending this” is answerable, precisely, without guesswork.

The Capacity Metrics App breaks consumption down by workspace, by item, by operation, and by user. You can drill into a timepoint where the capacity went over and see exactly which operations in which workspace drove the overage, and who submitted them. That’s the raw material for showback: an honest, per-team picture of who consumed what share of the capacity over a period.

Note the careful word. This is showback, not chargeback. Fabric doesn’t split one capacity’s bill into separate per-workspace invoices; the capacity is billed as a unit. What the Metrics App gives you is the consumption attribution. Turning that attribution into an internal cost allocation, and deciding who owns the number, is an organizational design choice rather than a platform feature, and it’s a question worth treating on its own terms rather than as a billing setting.

When to Split the Capacity

Once you can see per-workspace consumption, the structural lever becomes clear: workspaces can be reassigned to different capacities at any time.

That gives you a real tool for the noisy-neighbor problem. If one workload is volatile enough to keep throttling everyone else, you don’t have to over-size the shared capacity to absorb it. You can move that workload onto its own capacity, contain its blast radius, and size each capacity to its own load. The trade-off is that more capacities mean less pooling benefit (each smaller pool has less headroom to absorb a spike than one larger shared pool would), so splitting isn’t free. The decision is mechanical: split when isolation is worth more than pooling, keep shared when the smoothing across teams is doing useful work.

Hope for Lean Teams

You don’t need a complicated structure to run a shared capacity well. Three habits cover most of it.

Watch consumption by workspace in the Metrics App, not just total utilization, so you can name the source of a spike instead of guessing. When one workspace is repeatedly the cause of capacity-wide throttling, move it to its own capacity rather than sizing the shared one up for everybody. And run a periodic showback from the Metrics App so each team can see its own footprint, which tends to change behavior on its own once consumption stops being invisible.

That’s shared-capacity discipline for a lean team: make consumption visible, isolate the workloads that genuinely need it, and let the rest share the pool.

Where I Fit In

Shared capacity is where the clean mental model from Part 1 meets the messy reality of several teams and one bill. The mechanical decisions (which workloads can safely share a pool, which need isolating, how to read per-workspace consumption, and when a split beats a size-up) are exactly the calls that keep a multi-team estate from turning into a standing argument about whose fault the slowdown is.

If you’ve got several teams on one capacity and you want to see who’s really driving the consumption before you size up or split, let’s talk.

A shared capacity isn’t a billing detail, it’s an architecture decision. The teams that run it well make consumption visible, isolate the workloads that need it, and let smoothing do its job across the rest.

That closes our three-part run on capacity and cost. Next week we change lanes: DirectLake mode, and the quiet moment it falls back to DirectQuery without telling you.

Isaac Truong | Founder, Allston Yale

Enterprise-grade analytics for $50M–$100M SMBs

Power BI | Fabric | Azure | Data Strategy

Book a 20-min Fabric diagnostic →

Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)

LinkedIn: Connect with me for daily Fabric tips

Friday Fabric Facts #22: Originally Posted on LinkedIn, June 26, 2026