The research question
Where does the cost of Microsoft Fabric really come from, and how do you steer it with architecture?
Why it matters
Fabric is a SaaS platform with a shared capacity model. Unlike separate Azure services, you share a pool of Capacity Units across all workloads. Anyone who looks only at the SKU price misses where consumption really happens: in queries, transactions, and storage.
What the research says
The question behind capacity management is a classic systems problem: how do you share a compute pool without one user wrecking things for another. Das et al. (2013) showed in VLDB that naive CPU sharing in a multi-tenant database-as-a-service causes severe latency spikes from noisy neighbours, and that fine-grained reservation substantially reduces tail latency without under-utilising the shared resource. Verma et al. (2015) described with Borg at EuroSys how admission control and priority-based preemption enable high utilisation, and documented the price of that in contention. Rzadca et al. (2020) measured with Autopilot at Google that manually managed jobs carry 46 percent slack versus 23 percent for auto-scaled jobs: over-provisioning is the largest source of cloud waste. Dageville et al. (2016) showed with Snowflake in SIGMOD an architecture where compute and storage are strictly separated and each tenant gets its own cluster, sidestepping the shared-contention problem rather than solving it.
The product layer: Microsoft Learn describes Fabric as capacity-based. Workloads consume Capacity Units from a shared SKU, with smoothing and bursting to absorb peaks. OneLake storage is billed separately, and OneLake transactions themselves also consume Capacity Units. Copilot and Data Agent are token-metered into CUs, where input, cached input, and output carry different rates. Mirroring continuously replicates source systems into OneLake and adds storage and query consumption. Pausing and scaling capacity is the strongest cost lever for non-continuous workloads.
What the research does not prove
The line between what the studies actually establish and what we infer from them.
None of these studies is about Microsoft Fabric. They measure multi-tenant databases, Google clusters, and Snowflake. The pattern that utilisation and latency fight each other is robust, but exactly how Fabric's smoothing and bursting mechanics behave has never been measured scientifically. No peer-reviewed study of Capacity Units exists.
The textbook queuing result, that waiting time rises steeply as you approach full utilisation, is mathematically sound but does not tell you which threshold is right for your Fabric workload. That is why our headroom rule of thumb remains explicitly our own opinion and not a figure grounded in Microsoft documentation or research.
The Autopilot numbers come from long-running microservices at Google, not on-demand analytics queries. The slack percentage illustrates the mechanism; it does not transfer as a target value. And the Snowflake comparison only half applies: there each tenant gets its own cluster, whereas in Fabric workloads genuinely do contend for the same CUs.
Technical context
A Fabric capacity is a shared compute pool with a fixed SKU (F2, F4, and higher). All workloads (Data Engineering, Data Warehouse, Real-Time Intelligence, Power BI) draw from the same pool. Smoothing spreads short peaks over time; bursting temporarily allows more. If you structurally exceed it, the capacity throttles or you must scale up.
Architecture implications
- Pause capacity outside business hours for dev and test environments; that is often the biggest saving.
- Separate unpredictable, heavy workloads from interactive Power BI so a batch job does not throttle your reports.
- Watch OneLake transactions with many small files or shortcut-heavy patterns; they add up.
- Choose the SKU on peak behavior with smoothing in mind, not on the average.
Security implications
Governance runs through OneLake and the OneLake Catalog, integrated with Microsoft Purview. Security here is mostly access and classification at the item level; cost and security rarely cross directly, but a tight workspace design helps with both.
Cost implications
The three main sources are: capacity (the SKU itself), OneLake storage (separate, per gigabyte), and OneLake transactions (consuming CUs). On top of that come AI features: Copilot and Data Agent turn tokens into CU consumption, and mirroring adds storage and downstream queries. Pausing and scaling are the strongest levers. Reservations lower the SKU price for continuous use.
Adoption implications
Fabric is strong where you want integrated SaaS analytics with low integration overhead and Power BI consumption. Teams coming from separate Azure services often underestimate how quickly shared capacity fills up with multiple teams on one SKU.
Trade-offs
- One shared capacity versus several: simpler management versus isolation between teams.
- Pausing versus always-on: saves money but requires planning and can cause cold starts.
- Large SKU versus autoscale: predictable versus cost-efficient for spiky consumption.
Common mistakes
- Looking only at the SKU price and forgetting OneLake storage and transactions.
- Never pausing dev and test capacities.
- Letting heavy batch and interactive Power BI collide on the same capacity.
- Rolling out Copilot or Data Agent tenant-wide without first measuring token-to-CU consumption.
- Choosing the SKU on the average and then being surprised by throttling at peaks.
For architects
Model Fabric cost as three items (capacity, storage, transactions) and design the workspace and capacity layout on peak behavior and isolation needs. Pausing and separating workloads yield more than negotiating the SKU.
References
Grouped by source hierarchy. Research carries the reasoning, product documentation carries the implementation. Verify any of it yourself.
Methodology & confidence
The mechanism behind shared capacity rests on systems research into multi-tenancy and autoscaling: Das et al. (2013), Verma et al. (2015), Rzadca et al. (2020), and Dageville et al. (2016), all peer-reviewed at VLDB, EuroSys, and SIGMOD (tier 1). None of them is about Fabric, which we state explicitly above.
Microsoft Learn supplies the documented cost mechanics of Fabric capacity, licensing, OneLake consumption, and Copilot consumption (tier 3). The evidence level is mixed: the generic principle is well researched, the Fabric-specific detail rests on product documentation.
Peer-reviewed research
Journals, systematic reviews, meta-analyses, and reputable conference proceedings. This is the substantive basis.
- CPU Sharing Techniques for Performance Isolation in Multi-tenant Relational Database-as-a-ServiceDas, S., Narasayya, V., Li, F., Syamala, M. (2013). CPU Sharing Techniques for Performance Isolation in Multi-tenant Relational Database-as-a-Service. Proceedings of the VLDB Endowment 7(1), 37-48
- Autopilot: Workload Autoscaling at GoogleRzadca, K., Findeisen, P., Swiderski, J. et al. (2020). Autopilot: Workload Autoscaling at Google. European Conference on Computer Systems (EuroSys 2020)DOI 10.1145/3342195.3387524
- Large-scale Cluster Management at Google with BorgVerma, A., Pedrosa, L., Korupolu, M. et al. (2015). Large-scale Cluster Management at Google with Borg. European Conference on Computer Systems (EuroSys 2015)DOI 10.1145/2741948.2741964
- The Snowflake Elastic Data WarehouseDageville, B., Cruanes, T., Zukowski, M. et al. (2016). The Snowflake Elastic Data Warehouse. ACM SIGMOD International Conference on Management of Data, 215-226DOI 10.1145/2882903.2903741
Official technical documentation
How you build and configure it. Answers the implementation question, not the evidence question.
- Microsoft Fabric licenses and capacityMicrosoft Fabric licenses and capacity. Microsoft Learn
- OneLake compute and storage consumptionOneLake compute and storage consumption. Microsoft Learn
- Scale your Fabric capacityScale your Fabric capacity. Microsoft Learn
- Copilot in Fabric consumptionCopilot in Fabric consumption. Microsoft Learn
Continue across TechExplained
The same research, applied in other ways.