This query was rejected due to current capacity constraints

[marcdv]

Hello,

For the past two weeks, we have been encountering an error in Fabric Warehouse when executing queries that previously ran without issues. Something must have changed during the weekend of January 18th, 2025, which is now causing this error. Changing the capacity to F256, for example, doesn't make a difference, and restarting Fabric doesn’t help either. Is anyone else experiencing the same issue?

For instance, a query runs fine, but adding a simple ORDER BY or GROUP BY causes it to fail. It doesn’t even attempt execution—it fails immediately. It looks like the execution plan detects a percentage greater than 90% and just stops (SET SHOWPLAN_XML ON).

We are migrating from D365 Export to Data Lake to Fabric Link. The queries still work perfectly on Synapse Serverless but fail on Fabric.

[dzav]

@v-ssriganesh , @nilendraFabric , @DataBard, we started experiencing this issue as of 2025-02-04, and we'rve experienced this once before a few months ago (it resolved itself with no intervention).

We have two affected SQL views with some complex logic and return 600K - 1M rows. I tried creating and updating statistics, limiting the number of rows, and changing the VARCHAR(8000) field and other overly large fields to smaller sizes, but this did not help. Simplifying the view by removing some specific joins to CTEs resolved the issue, but this was not a workable solution as we needed the missing data to be included. Ultimately, I had to rewrite a column that was using ROW_NUMBER() OVER (ORDER BY x). We were using this in place of an IDENTITY column, which is not supported in Fabric warehouses.

In my opinion, this is a query engine bug.

[marcdv]

@v-ssriganesh , @nilendraFabric , @DataBard , sorry for the late reply.

Ok, let me explain. We are using Fabric Link in Power Platform to export data from D365 F&O to a Lakehouse within a workspace in Fabric.

We create a case-insensitive Warehouse in the workspace where we create views to the tables in the Lakehouse using a 3-part name reference. Then, we have views on these table views that combine different tables. This is the same as what we did on Synapse Serverless with views that used OPENROWSET.

No issues on Synapse Serverless—Fabric just can't pull it. If I run 5 queries in parallel on Fabric (F32), some queries just hang, without even giving timeouts or any errors. I need to execute them one by one to get a result.

To make it even better, if I connect a Synapse Serverless using OPENROWSET views to OneLake with Delta format, then there is no issue running in parallel.

I think the query engine of Fabric is not as good as the one in Synapse Serverless.

We are experiencing different scenarios with different customers. One gets "This query was rejected due to current capacity constraints", even though it didn’t happen a few weeks ago. Others just run the queries for hours or days without failing.

I guess Fabric isn't mature enough for this kind of workload with millions of rows and joins.

Things I tried : 

I've tried adding statistics on every column of every table in the Lakehouse. (Views in the Warehouse are based on these tables.) If I remove the ORDER BY or GROUP BY, the query runs without issue. Adding the GROUP BY/ORDER BY

makes it fail immediately without even trying to run the query.

There are no error messages in SHOWPLAN_XML.
No other intensive processing is showing up in the Capacity Metric App in Power BI.

This is the query plan for a group by that fails

Query plan

This is the query plan without group that works :

Query plan without group

[v-ssriganesh]

Hi @marcdv,

Thank you for the detailed insights and for sharing your observations. Given your extensive testing, it does seem like Fabric’s query engine might be encountering limitations when handling large-scale aggregations across complex joins.

Since Fabric is evolving rapidly, this could either be a known limitation or a recent regression. To get deeper insights and a possible resolution, we recommend raising a Microsoft Support ticket for further investigation. Below is the link to create Microsoft support ticket:
https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket

If this helps, kindly accept it as a solution and give a "Kudos" so other members can find it more easily.

Thank you.

[v-ssriganesh]

Hi @marcdv,

Could you please confirm if the issue has been resolved after raising a support case? If a solution has been found, it would be greatly appreciated if you could share your insights with the community. This would be helpful for other members who may encounter similar issues.

Thank you for your understanding and assistance.

[marcdv]

The issue has not been resolved at this point, I'm going to create some more tickets this week, because we are getting this at several customers now.

[v-ssriganesh]

Hi @marcdv,

Could you please confirm if this issue has been resolved? If it has, kindly mark it as the solution and share the details in the community to help other members.

Thank you.

[marcdv]

Hi @v-ssriganesh , no this is still not resolved. We open a lot of tickets with Microsoft to get the root cause of the issue.

[v-ssriganesh]

Hi @marcdv,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please accept it as a solution and give a 'Kudos' so other members can easily find it.
Thank you.

[v-ssriganesh]

Hi @marcdv,

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.

Thank you.

[v-ssriganesh]

Hi @marcdv,

Thank you for sharing the details of your issue. I also appreciate @DataBard for their insightful response and helpful links. Building on those suggestions, here are a few additional considerations that might help to resolving the issue:

• Have you tried manually updating the statistics on the affected tables?
• If the dataset is large, consider creating or optimizing indexes to improve performance.

• Since ORDER BY and GROUP BY cause immediate failures: Does the issue persist if you remove or modify these clauses?

• Are there any specific error messages or warnings in the SHOWPLAN_XML that could indicate the root cause?

• You mentioned that switching to F256 did not resolve the issue. Some additional checks:
• Have you monitored query execution in the Capacity Metrics app or Monitoring hub to see if other workloads are consuming high resources?
• If possible, test running a simpler version of the query on a lower-tier capacity (F8/F32) and compare performance.

If this helps, please Accept it as a Solution and drop a Kudos so other community members can find it more easily.
Thank you.

[nilendraFabric]

Hello @marcdv 

are the query without change like without order by also failing?

[DataBard]

Hi @marcdv,

An initial search of the forum suggests someone else asked this question last year. Here's a link to that (doesn't look like it was resolved): Fabric Warehouse - This query was rejected due to ... - Microsoft Fabric Community

I'd also take a look at the warehouse performance guidelines here: Warehouse performance guidelines - Microsoft Fabric | Microsoft Learn

That said, you've indicated the query plan has already shown high utilization. Here's some things I'd check next:

1. Are you currently doing anything in the environment to update statistics?
2. What specific action is the query taking, and across how many tables/records does this action occur?
3. What does capacity utilization look like in other areas of Fabric? Are there any other intensive processes showing up on the Capacity Metrics app or Monitoring hub?