Dataflow Gen2 Pricing in Microsoft Fabric - How the Meters Actually Work

The most common Fabric conversation we have with Australian clients right now isn't about features. It's about the capacity metrics app, a puzzled data lead, and a question along the lines of "why did our dataflows eat forty percent of the capacity last month?"

Dataflow Gen2 is the low-code transformation workhorse of Fabric - Power Query in the cloud, effectively, with 300-odd built-in transformations and now Spark-backed execution for mapping data flow workloads. It's approachable, which is exactly why it spreads through an organisation faster than anyone budgets for. Every analyst who ever built a Power Query in Excel can build a dataflow, and every dataflow burns capacity units. Understanding how it burns them is the difference between a predictable Fabric bill and a quarterly surprise.

Microsoft's pricing documentation for Dataflow Gen2 has all the rates, but it takes a couple of reads to see the shape of it. Here's the version I give clients, with opinions attached.

The four meters

When a Dataflow Gen2 refreshes, it can consume capacity units (CUs) through up to four separate engines, each with its own meter. This applies to all paid Fabric SKUs from F2 up; trial capacities aren't billed.

Standard compute is the mashup engine - the thing actually evaluating your Power Query steps. You're charged on query evaluation duration, per query. And here's the first thing most people miss: the rate depends on which flavour of dataflow you built. A Dataflow Gen2 with CI/CD support gets two-tier pricing - 12 CU per second for the first ten minutes of a query's run, then 1.5 CU per second after that. The older non-CI/CD dataflow gets a flat 16 CU per second for the entire duration.

Sit with those numbers for a second, because they contain a strong opinion from Microsoft. The CI/CD variant is cheaper from the very first second, and for anything long-running it isn't remotely close - a 40-minute query costs about 9,900 CU-seconds on CI/CD pricing versus 38,400 on the legacy rate. Nearly four times the price for the same work. If you have old non-CI/CD dataflows doing heavy lifting, migrating them is one of the few cost optimisations in Fabric that's basically free money, and you get source control in the bargain.

High scale dataflows compute kicks in when staging is enabled. Staged queries run through the Lakehouse and Warehouse SQL engines, and that engine time bills at 6 CU per second, reported at the workspace level rather than per item. Note that this is on top of standard compute, not instead of it.

Fast copy is the data movement meter - 1.5 CU per second of copy duration when fast copy connectors are in play. It's the cheapest rate on the board, which is Microsoft telling you that bulk data movement belongs on the copy path, not in the mashup engine. Listen to that hint.

Spark compute is the new one: when mapping data flow (MDF) transforms run inside a Dataflow Gen2, execution goes to Spark and bills at 1.5 CU per Spark core-hour. An 8-core cluster costs 12 CU per hour of execution. Two extra details worth knowing - Spark startup time counts toward the billed duration, and MDF debug sessions run on a fixed 8-core configuration billing 12 CU per hour whether you're doing anything or not. Close your debug sessions.

There's also a fifth charge lurking outside the dataflow itself: if you route through a Virtual Network data gateway, the gateway bills 4 CU for its uptime, additively, on its own meter. Uptime, not usage - a VNET gateway that's on all day is drawing capacity all day, regardless of how many refreshes actually passed through it.

The staging trap

Now the part that generates the most billing surprises, in our experience running Microsoft Fabric consulting engagements across finance, retail, and government clients.

Staging sounds like an implementation detail. It isn't - it's a pricing decision. When staging is on for a query, your data is written into staging storage and processed through the Warehouse SQL engine, and that 6 CU per second meter starts running alongside your standard compute. For genuinely large workloads that benefit from SQL-engine processing, that's a good trade. For a modest query that would have evaluated fine in the mashup engine alone, you've roughly tripled the meter count for no benefit.

The trap is that people enable staging (or leave it enabled) reflexively, because it feels like the safe option, and then never look at the workspace-level High Scale meter where the cost lands. Because that meter reports per workspace rather than per dataflow, the cost is also harder to attribute - it doesn't show up neatly against the item that caused it. We've found five-figure annual capacity waste in exactly this pattern more than once. The fix is boring: audit which queries actually need staging, disable it where they don't.

The same logic applies in reverse to fast copy. At 1.5 CU per second it's the cheap meter, so when a dataflow spends most of its runtime just moving data from source to destination, enabling fast copy shifts that work from a 12-16 CU meter to a 1.5 CU one. We've seen refresh costs drop by more than half from this toggle alone.

Actually calculating your costs

The docs give you the formulas, and they're worth wiring into a spreadsheet. For a CI/CD dataflow's standard compute:

CU-seconds = duration x 12                          (if under 600 seconds)
CU-seconds = 600 x 12 + (duration - 600) x 1.5      (if over)

Microsoft's own worked example: a 2,131-second query comes out at 9,497 CU-seconds, and a 913-second one at 7,670. Note what the tiering does there - the second query ran for 43 percent of the first one's duration but cost 80 percent as much, because most of both bills accrues in that expensive first ten minutes. A dozen short queries can quietly out-cost one long one. Consolidating lots of tiny dataflows into fewer, better-organised ones is good hygiene that happens to be cheaper.

To validate any of this against reality, you need the Fabric Capacity Metrics app, and honestly you need it regardless. It's the only accurate view of what your dataflows consume - filter by item name, check the operation durations, apply the formulas. The docs walk through this for each meter, and the numbers reconcile within rounding. If nobody in your organisation opens the metrics app monthly, you don't have a Fabric cost model, you have a Fabric cost hope.

One grumble while I'm here: the units in this pricing model are genuinely confusing. Rates quoted as "12 CU" that are actually CU per second, consumption in CU-seconds, Spark in CU per core-hour, and a worked MDF example in the docs whose units don't obviously line up. If it takes a consultant three reads, your finance team has no chance. Build the translation layer - a simple sheet converting CU-seconds into dollars against your capacity SKU - and share it internally. It's the single most defusing artefact you can bring to a "why is Fabric so expensive" meeting.

What we'd tell you to do this week

Four practical moves, in rough order of payoff.

Migrate legacy non-CI/CD dataflows to the CI/CD flavour. Same functionality, dramatically better rate on anything long-running, plus git integration. Start with your longest-running refreshes because that's where the two-tier pricing pays off hardest.

Audit staging. Turn it off where the query doesn't need SQL-engine muscle. Check the workspace-level High Scale meter before and after so you can prove the saving.

Turn on fast copy wherever your connectors support it and the dataflow is movement-heavy. Cheapest meter wins.

And put someone in front of the capacity metrics app on a schedule. Most of the Fabric cost horror stories we get called into weren't caused by expensive features - they were caused by nobody looking for six months. This kind of consumption governance is a standing part of the work we do through Data Factory consulting, and increasingly it's the first thing we set up, before any pipelines get built.

Rates do change, too - Microsoft explicitly reserves the right to adjust consumption rates with notice, so treat any spreadsheet you build as needing an owner, not a one-off. If your capacity bill has already gone somewhere unexpected and you'd like a second pair of eyes on the metrics, that's a conversation we're always happy to have.