Retail: capacity cost under control across seven countries

A retailer with seven country organisations ran everything on one shared Fabric capacity. The bill had tripled in eighteen months without anyone being able to explain why. At the same time users complained about reports loading slowly in the morning, while standard monitoring suggested the capacity was more than adequate.

The real problem was not the size of the amount but the absence of an owner. Seven countries shared one line item, so no country had a reason to change anything and the central team had no argument to refuse anything.

Three capacities instead of one. A production capacity with a reservation for the part that runs twenty-four hours a day, a shared development capacity paused outside office hours, and a separate capacity for the two countries with a different seasonal pattern.

Workspaces were reorganised so every workspace has exactly one owner. That was the heaviest intervention, because the old layout followed technical layers (bronze, silver, gold) rather than ownership. The medallion layers still exist, but now as schemas inside a country workspace rather than as workspaces in their own right.

Consumption is pulled daily from the Capacity Metrics app and written to OneLake as a Delta table, creating a history that reaches further back than the app's own window. Purview supplies the ownership information that links consumption to a country.

Split on ownership, not on technology. A capacity is the smallest unit with a price, so anyone splitting on technology can never attach an amount to a team. That the countries lose some economies of scale is accepted: the gain was not in the scale but in the behaviour that visibility provokes.

The own cost history in OneLake was needed because the Capacity Metrics app shows a limited window. Without your own history any comparison with last quarter is impossible, and it is exactly that comparison that reveals a trend before it becomes a problem.

One large capacity with tighter governance. Considered and dropped: the underlying problem is that nobody is an owner, and more rules on a shared pool do not fix that.

A capacity per country. Seven capacities is administratively heavy and would put the two smallest countries on a minimum size they structurally do not fill.

Everything pay-as-you-go with no reservation. Gives maximum flexibility but leaves a demonstrable discount on the table for the part of consumption that is demonstrably constant.

Three capacities means three places to watch, and a peak in one country can no longer be absorbed by quiet in another. That is deliberate: burst capacity anyone can eat is precisely what made cost unpredictable.

Reorganising the workspaces touched every existing deployment pipeline and cost a sprint of rework. That work was unavoidable once ownership drives the layout.

Microsoft Fabric for capacities, workspaces and the Capacity Metrics app. Power BI for the cost dashboards themselves, read via Direct Lake from the same OneLake tables. Microsoft Purview for ownership and the link between workspace and organisation.

• Split capacities on ownership, not on technical layer.
• Keep consumption history yourself; the app shows a window, not an archive.
• Only reserve after two months of real measurement, and only the constant part.
• Pause non-production capacity outside office hours and measure whether anyone notices.
• Publish consumption per country on a fixed day; irregular numbers steer nothing.

The largest saving did not come from a technical optimisation but from two reports nobody opened any more that refreshed every morning at six. Those were invisible as long as all consumption landed in one pool.

Throttling turned out to have been happening for months without standard monitoring flagging it. The complaint arrived as "the reports are slow" and was treated as a reporting problem, not a capacity problem. Since then the throttling chart sits on the same dashboard as the cost, because they are two readings of the same limit.