Lesson 1 of 8 · 10 min
How Fabric Capacity Really Bills
You cannot control a bill you cannot predict, and you cannot predict a Fabric bill by counting queries. The capacity model is different from paying per job, and most expensive decisions come from treating it as if it were not.
Think of a Fabric capacity as a reservoir with a fixed inflow. Every second, the capacity adds a fixed amount of compute. Every operation draws from it. Fabric lets you draw faster than the inflow for a while, then spreads the repayment across future time. Cost and throttling both make sense once you see the reservoir.
Capacity units and CU-seconds
An F SKU provides a fixed number of capacity units (CUs). An F64 provides 64 CUs, which means 64 CU-seconds of compute every second, continuously.
Operations are measured in CU-seconds. A semantic model refresh, a warehouse query, a Spark job, a pipeline copy, and a data agent question each consume some number of CU-seconds. That number depends on the engine and on how much work the operation did, not on how long a user waited.
Three conversions are worth keeping nearby:
| Window | F64 budget |
|---|---|
| One second | 64 CU-seconds |
| One 30-second timepoint | 1,920 CU-seconds |
| One day | 5,529,600 CU-seconds, or 1,536 CU-hours |
The 30-second timepoint matters because the Capacity Metrics app evaluates utilization in 30-second slices. When you read a utilization percentage, you are reading consumption in a timepoint divided by the budget for that timepoint.
You pay for the reservoir, not the drops
On pay-as-you-go, an F SKU is billed per hour for its size while it is running. An F64 that sits idle at 2:00 AM costs the same per hour as an F64 running the month-end close.
This changes the cost question. The question is not “how much did that query cost?” It is “how large does the reservoir need to be for the work we actually run, and how many hours do we need it?” Individual operations matter because they decide whether the work fits, not because each one adds a line to the invoice.
Interactive and background work
Fabric classifies every operation as interactive or background, and treats the two differently.
- Interactive operations are triggered by a person waiting for an answer, such as report queries and many on-demand requests.
- Background operations are scheduled or long-running work, such as refreshes, pipelines, Spark jobs, and data agent AI processing.
The classification decides how the consumption is spread over time, and which work is affected first when the capacity is under pressure.
Bursting and smoothing
Bursting lets an operation use more compute than the SKU provides at that instant, so it can finish quickly instead of waiting for headroom.
Smoothing then spreads the CU-seconds of that operation across future timepoints:
- Interactive operations are smoothed over at least five minutes and up to 64 minutes, depending on consumption.
- Background operations are smoothed over 24 hours.
Smoothing does not make anything cheaper. It changes when the consumption is counted against the budget.
An illustrative example shows why this matters. Suppose a nightly refresh consumes 1,200,000 CU-seconds. Smoothed over 24 hours, that is 2,880 timepoints of about 417 CU-seconds each. Against an F64 timepoint budget of 1,920 CU-seconds, that one refresh occupies roughly 22% of the capacity for a full day after it runs. Teams are often surprised that a job they think of as “overnight” is still visible at lunchtime. Smoothing is the reason.
Carryforward and throttling
When smoothed consumption keeps arriving faster than the capacity can absorb it, the excess becomes carryforward: compute you have already used from future timepoints. Idle capacity pays it down. If it keeps growing, Fabric protects the capacity in stages.
| Future capacity already consumed | Stage | Effect on new work |
|---|---|---|
| Up to 10 minutes | Overage protection | No throttling |
| 10 to 60 minutes | Interactive delay | New interactive operations wait 20 seconds at submission |
| 60 minutes to 24 hours | Interactive rejection | New interactive operations are rejected |
| More than 24 hours | Background rejection | New interactive and background operations are rejected |
Operations already running are allowed to finish. Lesson three turns this table into a diagnostic method.
The meters outside the capacity
The capacity is the largest line on most Fabric bills, but it is not the only one. A cost model that ignores these will be wrong in predictable ways:
- OneLake storage is billed per GB at a pay-as-you-go rate and does not consume CUs. Soft-deleted data is billed at the same rate as active data until it is purged. OneLake reads and writes do consume CUs from the capacity.
- Mirroring storage includes a free allowance that scales with the capacity SKU. Storage above that allowance is billed as OneLake storage.
- On-demand billing for Spark (previously called Autoscale Billing for Spark), when enabled, moves Spark jobs off the shared capacity onto a separately billed serverless meter with a maximum CU limit you set.
- Capacity overage, when enabled, pays for excess usage that would otherwise throttle, at three times the pay-as-you-go rate. Microsoft enables it by default on new capacities, so check whether yours has it on. Lesson six covers it in detail.
- Pausing a capacity bills any remaining smoothed and burst consumption at the moment of the pause.
- Reservations change the rate for the CUs you reserve. They do not change how much work the capacity can run.
The licensing line at F64
At F64 and above, users with a free license and a viewer role can read Power BI content in the capacity. Below F64, every viewer needs a Pro or Premium Per User license. For an organization with many report readers, this can make F64 the cheapest total option even when a smaller SKU would handle the compute. Sizing is a compute decision and a licensing decision.
Exercise: write down your bill model
Before you open any tooling, write a one-page model of your current or planned Fabric spend.
| Meter | Current setting | Monthly driver | Owner |
|---|---|---|---|
| Capacity SKU and hours | |||
| Reservation coverage | |||
| OneLake storage, including soft-deleted data | |||
| Mirroring storage above the free allowance | |||
| On-demand billing for Spark | |||
| Capacity overage | |||
| Viewer licensing below F64 |
Mark every cell you could not fill in. Those gaps are where surprises come from, and the rest of the course gives you the evidence to close them.
Carry this forward
A model is a hypothesis. The next lesson shows you where to find the evidence: the Capacity Metrics app, and the baseline you should record before you change anything.