Why Dataflow Gen2 is the #1 CU hog in Microsoft Fabric (and 5 fixes to cut its cost by 70%)

By The CostFabric team · 27 October 2026 · 9 min read

Across the Microsoft Fabric Capacity Metrics exports we review every month, one item type consistently ranks as the #1 consumer of Capacity Units (CUs) on F8 through F64 tenants: Dataflow Gen2. It is common to open a throttled F32 or F64 capacity and find that three or four Dataflow Gen2 refreshes account for 55–75% of all 24-hour smoothed background CUs—costing more in compute than every Power BI semantic model and Spark notebook combined.

Why does Dataflow Gen2 consume so many CUs in Microsoft Fabric, and how can you cut Dataflow Gen2 cost by 60–85% without rewriting your whole platform? This engineering guide explains the billing mechanics of Mashup engines, Lakehouse staging, Fast Copy, and when to switch to Data Factory Copy Activity or PySpark notebooks.

Why Dataflow Gen2 is the #1 CU hog on F8–F64 capacities

To understand why a 500,000-row table load can consume tens of thousands of CU-seconds in Dataflow Gen2, trace what happens under the hood during a default execution:

1. Power Query Mashup Engine evaluation: Every query runs inside Mashup containers that consume high CU rates per v-core second whenever transformations (joins, sorts, group-bys, fuzzy merges, or custom M functions) break query folding and force row-by-row evaluation in memory.
2. Hidden Lakehouse Staging (double write + SQL compute): When staging is enabled on a Dataflow Gen2 query (or required by a Warehouse destination), Fabric first writes Mashup output as Parquet files into an internal DataflowsStagingLakehouse, then spins up internal SQL/Warehouse compute to read that staged data and write it a second time to your destination table.
3. System staging artifacts bill against your capacity: In the Capacity Metrics app, heavy CU consumption appears not only on your named Dataflow Gen2 item, but also on hidden workspace items named DataflowsStagingLakehouse and DataflowsStagingWarehouse. All three bill directly against your capacity's 24-hour background smoothing pool.

5 proven fixes to cut Dataflow Gen2 CU consumption by 60–85%

Before you upgrade from an F32 to an F64 (or F64 to F128) to stop CapacityLimitExceeded throttling, apply these five engineering fixes to your heaviest Dataflow Gen2 items:

1. Disable Staging on simple ingestion and passthrough queries

In Power Query Online inside Dataflow Gen2, Enable staging is turned on by default. Staging only helps when you perform heavy, multi-table joins across multiple queries inside the same dataflow so the Warehouse engine executes the join instead of the Mashup engine.

If a query simply reads from a source, applies light column filters/renames, and writes to a Lakehouse table, right-click the query in the Queries pane and uncheck Enable staging. Disabling staging removes the intermediate write to DataflowsStagingLakehouse and cuts the query's CU footprint by 35–50%.

2. Turn on Fast Copy for bulk data movement

When ingesting large tables from supported databases, storage accounts, or gateways, enable Fast Copy in Dataflow Gen2 Options → Scale (and on the query indicators). Fast Copy bypasses the single-threaded Mashup row evaluator and routes bulk transfers through the high-throughput Data Factory Copy backend, slashing duration and CU-seconds.

3. Replace pure ingestion Dataflows with Data Factory Copy Activity

If a Dataflow Gen2 has no complex M logic and exists only to copy tables from SQL Server, PostgreSQL, Oracle, REST APIs, or SharePoint/ADLS into a Bronze Lakehouse, replace it with a Data Factory Copy Activity inside a Data Pipeline (or use Mirroring where supported). Copy Activity moves raw data at a fraction of the CU cost per gigabyte.

4. Enforce query folding and configure Incremental Refresh

Check the step folding indicators in the Applied Steps pane:

• Folded steps push WHERE, GROUP BY, and JOIN work back to the source database at zero Fabric Mashup compute cost.
• Not folded steps (such as Table.Buffer, index columns before filtering, or type conversions on join keys) pull raw tables into Fabric memory. Move filters and column removals to the earliest steps so they fold.
• For fact tables with a watermark timestamp, enable Incremental Refresh so Dataflow Gen2 processes only the last 1–3 days of changes instead of reloading years of history every hour.

5. Use High-Concurrency PySpark Notebooks or SQL Stored Procedures for Medallion transforms

For Silver-to-Gold transformations across millions of rows, moving logic from Dataflow Gen2 into a Fabric PySpark Notebook (with High Concurrency mode enabled so multiple notebooks share one warm Spark session) or a Warehouse T-SQL Stored Procedure cuts compute consumption by 70–85%. Lower background CUs also drastically reduce the 24-hour smoothing carryforward debt billed when you pause a PAYG capacity.

Decision table: Which Fabric ingestion & transform tool should you use?

Audit your Dataflow Gen2 costs in 10 minutes

Open the Microsoft Fabric Capacity Metrics app on the Compute page, filter the Items table by Item Kind = Dataflow (plus DataflowsStaging* Lakehouses/Warehouses), and paste your 14-day export into our free Excel Fabric Capacity Savings Checker. Then check how stepping down one SKU tier lowers your monthly bill in our interactive savings calculator or our complete F-SKU PAYG vs Reserved pricing guide.

Frequently asked questions

Why does Dataflow Gen2 use so many Capacity Units (CUs) in Microsoft Fabric?

Dataflow Gen2 runs the Power Query Mashup engine and, by default, stages data into an internal DataflowsStagingLakehouse and DataflowsStagingWarehouse before writing to the final destination. When query folding breaks or staging is left enabled on simple loads, you pay for Mashup evaluation plus double storage/SQL compute writes across a 24-hour background smoothing window.

Should I disable staging in Fabric Dataflow Gen2?

If a Dataflow Gen2 query ingests and transforms data in a single pass and writes to a Lakehouse without performing heavy multi-table joins across already-staged queries, disabling staging eliminates the intermediate Lakehouse write and typically reduces CU consumption by 35–50%.

What is the cheapest alternative to Dataflow Gen2 in Microsoft Fabric?

For raw table ingestion into OneLake, Data Factory Copy Activity (or Database Mirroring) consumes 75–90% fewer CUs than Dataflow Gen2. For multi-million-row transformations, PySpark Notebooks running in High Concurrency mode or Warehouse T-SQL stored procedures typically consume 70–85% fewer CUs.