Fabric Warehouse's one-minute floor turns your cheapest queries into your dearest ones

Microsoft will stop metering Fabric Data Warehouse compute by per-query CPU time in August 2026 and start metering per-workspace virtual-node time instead, a change that also covers the SQL analytics endpoints of Lakehouse ^[1][2]. That shifts the billed unit from work performed to capacity held open, and it puts a 60-second floor under every workspace that wakes up ^[7].

The mechanics below come from a technical breakdown by Gilbert Kiptoo Lelon on dev.to, which cites Nikola Ilic's write-up, Microsoft documentation, and the author's own client work in US and European markets ^[15]. A virtual node is a 4-vCore unit of Warehouse compute that Fabric allocates automatically according to demand ^[3]. The per-vCore rate drops from 2 CU to 0.53 CU ^[4][5], which makes an active virtual node worth 2.12 CU ^[6], or 26.5 percent of the old per-vCore rate ^[1]. Below one minute of Warehouse activity, uptime is rounded up to 60 seconds per workspace; above it, billing is per second ^[7].

The floor is the whole story. One virtual node held for the minimum minute costs 127.2 CU-seconds, whether the query inside it ran for 20 seconds or two ^[8]. On the source's own unit definitions, matching that under the old 2 CU per vCore rate would have taken about 63.6 vCore-seconds of billed CPU time, or roughly 3.2 vCores fully busy for the whole 20 seconds ^[4]. A trivial dashboard query does not do that. As Lelon puts it, the new model charges for the allocation window rather than the useful work inside it ^[9].

Density is the lever. Run five queries inside that same first minute and the charge is still 127.2 CU-seconds ^[10], which is 25.44 CU-seconds per query ^[2]. Nothing got faster; the window simply got used. At the other end of the scale, ten virtual nodes running a 20-minute transformation come to 25,440 CU-seconds, with the minimum irrelevant at that duration ^[11]. That entire ETL window costs exactly as much as 200 lonely single-query wakeups ^[3]. If those nodes are genuinely busy with scans, joins and aggregations, the lower per-vCore rate can reduce consumption against the old CPU-time model ^[12].

So the cost profile inverts. Lelon's argument is that dense ETL may get cheaper while sparse, chatty workloads (dashboards, monitoring probes, single-query wakeups) may get significantly more expensive, not because the queries changed but because the floor did ^[13]. Two design habits become liabilities. Frequent low-cost polling now pays a full minute of node time per wake-up ^[7][8]. And because the floor is per workspace, splitting the same query volume across many workspaces multiplies the number of floors you pay rather than the work you get ^[2][7].

Two caveats worth keeping. The arithmetic uses Microsoft's stated unit definitions and is not a dollar figure; actual cost depends on your F-SKU pricing and on how many virtual nodes Fabric decides to allocate ^[14]. And that allocation is automatic ^[3], which is the number no one controls.

What to watch: whether Microsoft exposes virtual-node allocation counts in capacity telemetry before August 2026, since without them the 2.12 CU per node figure ^[6] cannot be turned into a forecast. Then watch your own probe cadences and workspace count, which are the two things you can change without touching a query.