How Much Does Microsoft Fabric Cost? CU-Seconds and What Drives Your Bill

Every Microsoft Fabric conversation starts with the same question: what will it cost us? And the honest answer has always been “it depends” — because Fabric is billed by capacity, not by the job. What you need depends on what you run, how you build it and when people use it. This guide explains how Fabric billing actually works, what drives the bill the most, and how to size and control it — with figures from a detailed public benchmark to make it concrete.

How Fabric billing works: capacity and CU-seconds

Fabric is sold as capacity. Each SKU is a number of capacity units (CUs): an F2 has 2, an F4 has 4, an F64 has 64. You are not charged per pipeline or per query — everything you run draws from that shared capacity.

The useful mental model is a daily budget. Background work such as a data load is smoothed over 24 hours, so an F2’s 2 CUs become 2 × 86,400 = 172,800 CU-seconds a day, and an F4 gives twice that. Every cost in Fabric can be expressed in CU-seconds and held up against that daily budget to tell you how large a capacity a workload really needs. For the price of a SKU in your region, see Microsoft’s Fabric pricing page.

What actually drives your bill

Here is the part most sizing exercises miss: two teams can load the same data and get very different bills, because how you build matters as much as how much data you have. A detailed independent benchmark presented at FabCon 2026 (Birch Run Consulting) loaded 1, 10 and 100 million rows across seven tools and three destinations on a dedicated F4, three runs each. The patterns it measured match what we see in client tenants — and they are worth understanding before you size anything.

1. How you load the data

The loading tool is the single biggest lever. Notebooks that close their session when the work is done used a fraction of what dataflows and pipeline copy used at scale:

Mean CU-seconds, three runs on an F4. Lower is cheaper. Source: Birch Run Consulting benchmark.

A Python or Spark notebook that ends its session loaded 100 million rows for a few hundred CU-seconds — well under 0.2% of an F2’s day. The same load through a Dataflow Gen2 cost roughly 15 to 20× more. Dataflows are convenient and low-code, but that convenience has a measurable price at volume.

2. Where you load it

The destination matters too. Loading into a lakehouse was consistently cheapest; a warehouse cost more (up to several times more for some tools); and a Fabric SQL database cost the most of all — because the database keeps its compute online for 20 to 45 minutes after the load finishes, and that running time is billed to your capacity. Most of a SQL-database load’s cost is the database idling afterwards, not the load itself.

3. Idle Spark sessions — the silent cost

A Spark session keeps consuming capacity until it ends. In the benchmark, the same 1-million-row load cost about 45× more when the session was left to time out (around 20 minutes) instead of being closed when the work finished:

Source: Birch Run Consulting benchmark, 1M rows into a lakehouse on an F4.

The lesson is blunt: close your sessions. Run notebooks from a pipeline or the job API so the session ends with the work, and do not leave interactive sessions open. Idle time, not table size, dominates the cost here.

4. Direct Lake vs Import — the refresh trap

Loads are only half the bill; reporting is the other half. Build the same 100-million-row model two ways and the refresh cost is night and day:

Source: Birch Run Consulting benchmark, on an F4. Viewing the report cost about the same on either model.

An Import refresh copies all 100 million rows into the model every time it runs — and a model refreshed several times a day pays that several times a day. A Direct Lake model simply points at the latest version of the table in OneLake: 22 seconds, near-zero cost. Viewing the report cost about the same on either model, so for large tables refreshed often, Direct Lake is one of the biggest cost decisions you will make. It is a core choice in our Fabric architecture design system.

So, how much is Fabric for you?

There is no single price — but there is a reliable way to find yours. When Microsoft’s own leadership were asked this at FabCon, their answer was: use the trial. Run a representative slice of your real workload on the Fabric trial (an F64) or a small pay-as-you-go capacity, measure the CU-seconds it consumes with the Capacity Metrics app or capacity events, and size from there — dividing the trial’s F64 by the SKU you actually plan to buy. A realistic load on your data beats any spreadsheet estimate.

How to keep the Fabric bill down

• Pick efficient load patterns — favour notebooks that close their session over heavy dataflows for large, simple loads.
• Close Spark sessions — run from pipelines or the job API; never leave interactive sessions idling.
• Prefer Direct Lake for large tables to avoid repeated full Import refreshes.
• Right-size, then reserve — baseline on the trial or a zero-provisioned F0 before committing to a reservation.
• Pause idle capacity — non-production capacity should not run overnight.
• Monitor continuously — watch CU consumption by workload so spend is a decision, not a surprise.

What the numbers don’t tell you

Treat every benchmark, including this one, as a direction, not a quote. The figures above are one dataset (three narrow columns, no transformations), one region, one SKU, one point in time — and Fabric changes every month. Wide or messy data, real Power Query work, and your own usage patterns will all move the numbers. The value is in the patterns: load method, destination, idle sessions and Direct Lake vs Import are where the money is.

Sizing a Fabric capacity? We can run these tests on your data in your own tenant and give you a defensible number — part of our Microsoft Fabric consulting in the UAE.

Benchmark figures: Birch Run Consulting, “How Much is Fabric? What We Measured” (Nathan Giullian & Jim Hill, FabCon 2026), measured on a dedicated F4/F8. SKU pricing via the Microsoft Fabric pricing page. CU-second figures are illustrative of the patterns, not a quote for your workload.