Capacity rather than licence Tetris

Anyone who runs a modern data platform is familiar with the question that regularly crops up during annual budget discussions: “How much will the solution cost us next year?” In a traditional, tool-centred platform environment, the answer is honest — but unsatisfactory: “It depends.”

It depends on how many teams are growing. It depends on how many pipelines run each day. It depends on whether compute resources are shut down properly or continue to run unnoticed. And whether licences have been purchased for peak load or average load. Both are expensive — just in different ways.

Microsoft Fabric tackles this question with a fundamentally different approach: the capacity model. What this means, where it helps — and where requirements remain — is the subject of this article.

The classic model: licence plus infrastructure plus operations

A conventional data platform consists of individual components. A data warehouse here, an ETL tool there, a BI layer on top, plus cloud computing for transformations and storage for the raw data. Each component has its own pricing model:

• Licence costs: per user, per core, per node — contractually binding
• Cloud compute: Pay-as-you-go: every pipeline, every Spark job, every query
• Cloud storage: Per GB stored + per GB read/written
• Operations & DevOps: Monitoring, patching, scaling, incident handling
• Network costs: Data transfer between services, regions, egress

The result is a cost structure with several variable components. Some of these can be planned for, such as licences for a known number of users. Others are far less predictable: How many GB will be transformed next month? How many ad hoc queries will the analyst team run? How much rendering will be required when a new reporting dashboard goes live?

Two strategies, both with their drawbacks

Companies typically tackle this uncertainty with one of two strategies — or a combination of both.

The first strategy is over-provisioning: resources are procured to cater for the expected peak load. This ensures that no bottlenecks arise — but during normal operations, a significant proportion of the paid-for capacity lies idle. A classic example is a dedicated SQL warehouse designed for the month-end closing, but which runs at half capacity for 27 out of 30 days.

The second strategy is active resource management: you configure auto-scaling, schedule shutdown windows, set budget alerts and train teams to start and stop resources properly. This works, but it requires ongoing effort, such as reliable monitoring across all services and the discipline to stick to it consistently.

• Over-provisioning
  Safe, but expensive — capacity for the peak that rarely occurs
• Active management
  Flexible, but labour-intensive — continuous monitoring & control
• The result
  Both approaches create budget uncertainty and operational overhead

The Fabric Capacity model: a metric that breathes

Microsoft Fabric replaces this patchwork with a single control metric: Fabric Capacity, measured in Capacity Units (CU). One Capacity Unit covers all workloads running within the allocated workspaces — data engineering, data warehousing, real-time analytics, Power BI, data science and more. There are no separate infrastructure costs, no cloud operating expenses, no egress surprises. Platform operation is included in the SaaS price.

The only remaining cost component directly linked to usage is the data stored in OneLake — this is the easiest part to plan for and the most cost-effective compared to compute.

The fundamental difference from the traditional approach: the Capacity model is not designed for peak usage, but for the expected average. What happens if this average is exceeded — e.g. due to a large data load or an intensive analysis session — is governed by the burst and smoothing mechanism.

Burst and smoothing: capacity that incurs and repays ‘debt’

If a workload temporarily consumes more CUs than the capacity size nominally permits, Fabric does not intervene immediately. Instead, the excess is recorded as an internal debt. The platform allows the burst to occur — and offsets it during periods of low utilisation by consuming less capacity than would otherwise be available.

Principle: Burst & Smoothing over time

• Capacity limit: 100%
• Peak load – Burst: Debt is incurred
• Smoothing balances things out
• Average – basis for planning
• Idle – debt is reduced

This ‘breathing’ makes the capacity limit the basis for planning the average — not the worst-case scenario. As long as load peaks are temporary and alternate with periods of inactivity, the platform remains stable without the need to scale.

Important: Debt tolerance is not unlimited. When accumulated burst debt reaches a threshold, Fabric responds in stages: initially, new tasks are delayed (throttling); if the threshold is exceeded further, they are rejected (rejection). Monitoring these thresholds is therefore an essential part of capacity management.

Planning based on averages: the same fundamental problem — solved differently

Let’s be honest: the capacity model does not solve the problem of load estimation. Here, too, one must estimate how intensively the platform is used on average. This estimation is particularly difficult at the outset — and remains a challenge in dynamically growing data landscapes. However, the model can be operated ‘on an ad hoc basis’.

The capacity model offers significantly greater responsiveness: if the capacity selected is too small, it can be increased with just a few clicks. If it is consistently oversized, it can be scaled down. There are no contract terms per individual component, no waiting times for cloud resources, and no rounds of negotiation. A capacity slider in the Azure Portal is all the admin needs.

Workspace structure as a lever: workload management

An often underestimated advantage of the Capacity model lies in the ability to operate multiple capacities and assign workspaces flexibly. This opens up a new dimension of control: workload management at organisational level.

In concrete terms, this means that an organisation can create different capacities for different usage profiles. A large capacity for daily, intensive production. A smaller one for development and testing. A dedicated one for time-critical real-time analyses. When a project ends or a team moves into a new phase, the workspace is simply assigned to a different capacity — without data migration, without new configuration.

• Production (F64)
  Daily pipelines, reporting, real-time — high utilisation, stable
• Development (F8)
  Experiments, new features, data products — intermittent
• Burst reserve (F16)
  Month-end closing, batch runs, seasonal peaks — temporary

This flexibility allows you to concentrate expensive capacity where it is currently needed — and to optimise overall costs across the portfolio, rather than over-provisioning each application individually.

Monitoring remains, but with a dashboard

Even though the capacity model greatly simplifies cost complexity, monitoring cannot and should not be dispensed with. The Fabric Capacity Metrics App is the central tool for this. It shows, almost in real time, how many CUs are being consumed, which workloads are using the most capacity, when burst debt is accumulating, and whether thresholds are being approached.

Monitoring objectives and action strategies in the Capacity model

• Persistently high utilisation: Capacity upscaling — a one-off step, not a contract
• Burst debt is accumulating: Check load balancing or reassign the workspace
• A single workload dominates: Move the workspace to its own capacity
• Capacity is persistently low: Downsizing — reduce costs without service interruption
• Approaching thresholds: Use alert configuration for proactive intervention

The key difference from the traditional approach: you no longer monitor many different services with different metrics and dashboards. One dashboard, one family of metrics, one set of action rules. This significantly reduces the cognitive load — and makes alerting more targeted.

Where the model has its limitations: items with fixed resource allocation

The capacity model with burst and smoothing assumes that workloads can be started and stopped as required — in other words, that they support a serverless operating model. This is the case for many Fabric workloads: dataflows, notebooks, pipeline runs and Power BI queries run on-demand and release resources when they are finished.

However, some Fabric items operate differently. They require infrastructure that runs continuously — and therefore reserve a fixed proportion of CUs within the allocated capacity:

Item/Service – Reason for fixed CU reservation

• Event streams: Continuous stream processing; no pauses possible
• Spark clusters (always-on): Warm clusters for minimal latency when jobs start
• SQL databases (Fabric DB): Persistent query engine must respond at all times
• Real-time dashboards (KQL): Low query latency requires available compute

The following applies to these items: When designing capacity, you must factor in how many CUs they permanently occupy — and allocate the remaining ‘free’ portion to dynamic, serverless workloads. If capacity is set too low here, it can result in limited scope for burst tolerance.

Recommendation: Explicitly track items with fixed CU reservations in the Capacity Metrics app. The ‘background’ consumption of these items is predictable — and forms the baseline against which all dynamic workloads are added.

A direct comparison at a glance

• Dimension: Cost basis
  Traditional model: Licence + infrastructure + operations
  Fabric Capacity: One capacity unit (CU)

• Dimension: Scaling logic
  Traditional model: Designed for peak load — or manually controlled
  Fabric Capacity: Designed for average load, with peaks handled via burst

• Dimension: Peak loads
  Traditional model: Immediate costs or manual throttling required
  Fabric Capacity: Burst + Smoothing: Debits are internally offset

• Dimension: Responsiveness
  Traditional model: Procure new contracts / resources
  Fabric Capacity: Scale capacity up or down in just a few clicks

• Dimension: Workload control
  Traditional model: Configurable individually per tool
  Fabric Capacity: Workspace-based capacity management

• Dimension: Predictability – Budget
  Traditional model: Uncertainty due to variable proportions
  Fabric Capacity: Fixed budget, predictable monthly costs

• Dimension: Monitoring
  Traditional model: Multiple tools, different metrics
  Fabric Capacity: Fabric Capacity Metrics App — a dashboard

• Dimension: Fixed resources
  Traditional model: Dedicated tier sizes per service
  Fabric Capacity: Item-specific CU reservation possible

Conclusion: A different way of thinking, not just a different pricing model

Microsoft Fabric’s Capacity model is not merely a change of licensing. It changes the way we think about the costs of a data platform. Instead of procuring, monitoring and optimising resources for each service individually, you work with a single budget lever — the Capacity size — and a clear mechanism for load dynamics: burst and smoothing.

This does not mean that all questions disappear. Estimating the average load remains a challenge. Monitoring and alert handling are still necessary. And for items with ongoing resource requirements, reservations must be planned carefully.

What does change fundamentally, however, is that options for action become faster, cost transparency increases and organisational control becomes more flexible. Capacity can be adjusted on a daily basis. Workspaces can be reallocated. And budget discussions finally yield an honest, predictable answer.