Capacity for warehouse increased abnormal

Hi,

Sadly a lot of users are experiencing issues with the changes in how warehouse queries are billed. This came quite unannounced (only the subscription owners with a Fabric capacity received a mail, but nobody expected the impact to be so big)
There is a blog about what changed: One-minute trap! How new Fabric Warehouse CU metering affect your workloads - Data Mozart.

I am still looking for ways to reduce the load in a way, as we experience the same issue.. 

Many tks JVDA98​ , now i understand why CUs increased abnormal. Hope you can sharing the ways to reduce the load after looking for. Of cause i will share too if i find out something better

Hi QuangThanh​,

Thank you for reaching out to Microsoft Fabric Community.

Thank you JVDA98​ and ShivekMaharaj​ for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the response provided by the user's for the issue worked?  or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

Hi QuangThanh​,

The timing you are seeing is interesting because Microsoft's current Warehouse consumption documentation now describes a different consumption model based on allocated compute over time.

Fabric Warehouse now measures consumption using dynamically allocated vNodes, with consumption conceptually being Active vNodes × Active Time. Microsoft also documents a one-minute baseline allocation window, after which consumption is measured per second based on the number of allocated vNodes.

You may access the current guidance on Warehouse usage reporting here.

So I would not assume that your Warehouse queries suddenly became 2.5x more expensive computationally just because the CU(s) increased. Under the current model, workload shape matters as well. For example, concurrency can cause additional vNodes to be allocated, and Microsoft also includes system-generated Warehouse activity in consumption.

Before considering an F64 resize, I would compare one representative period before and after the increase:

1. Use Capacity Metrics to identify the highest Warehouse CU time windows.
2. Use queryinsights.exec_requests_history and queryinsights.frequently_run_queries during those windows.
3. Compare query count, concurrency, execution patterns and whether the activity is user-generated or system-generated.

Microsoft specifically recommends using Capacity Metrics together with Query Insights for investigating unexpected Warehouse consumption.

If you find many short queries running repeatedly, or bursts of concurrent queries, I would look at reducing unnecessary polling/chattiness or consolidating those workloads before scaling the capacity.

I also would not use the higher CU number alone to conclude that F64 is insufficient. Check the actual throttling/carryforward state in Capacity Metrics first. If the capacity remains healthy, the higher reported CU consumption may mainly reflect the changed metering model rather than an immediate capacity-sizing problem.

I cannot find a public Microsoft statement confirming that every tenant switched specifically on August 11, so I would avoid tying your exact cutover date to the change without Microsoft confirming that part.

similar issue here, one warehouse went from 20 000 cu to 200 000 and other went from 60 000 to 140 000.

Hi @QuangThanh,

Before resizing the capacity, i would recommend you must double verify this upgrade by Microsoft.  
If you have fabric capacity metric app installed, please check the consumption of CU before 11 Aug 2026 and after that date and filter to warehouse level consumption which gives the accurate results.

I would suggest to open a Microsoft support case if this is causing your F64 to throttle.

The timing and cross-warehouse impact are strong enough to open a Microsoft support ticket that I would ask Microsoft to confirm whether a backend Warehouse change or consumption-rate/attribution change was deployed around August 11, 2026 or not and Fabric throttling occurs when consumption exceeds the capacity's available CU resources.  So this help to solve the concern of fabric capacity stability is legitimate.

 If this helps, ✓ Mark as Kudos | Help Others

Hi QuangThanh​ ,

i imagine it might also have something to do with the GPU extension that can now be enabled.
Perhaps Microsoft has made some internal changes that are currently causing these increases in CUs, even though the feature hasn't actually been enabled.

Here are the article.

We Put a GPU Behind Fabric DW | Microsoft Fabric Community

Many greetz
spaceman127

Hi QuangThanh​,

We wanted to kindly follow up to check if the response provided by the user's for the issue worked?  or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa