Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

View all the Fabric Data Days sessions on demand. View schedule

Reply
Sania-F
Resolver I
Resolver I

kusto error- partial query failure

hi all,

 

error - Details: "Query execution has exceeded the allowed limits (80DA0001): Partial query failure: Runaway query (E_RUNAWAY_QUERY). (message: The Join output block has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY; see https://aka.ms/kustoquerylimits).: ).
[0]Kusto.Data.Exceptions.KustoServicePartialQueryFailureLimitsExceededException: Query execution has exceeded the allowed limits (80DA0001): Partial query failure: Runaway 

 

I am trying to join 5 tables in kusto to fetch all required columns , 3 tables from 1 cluster ans 2 from another cluster. But query is failing with memory error

 

Dummy query :

 


let onboarded = Pln
| project STId;

let regAss = external_table('PR')
| where Region == 'France'
| where Status !in ("Error", "Rejected")
| project STId;

let exeAppr = external_table('PR')
| where Region == "France" and Status in ("Ready", "Approved")
| project STId, Region, Status;


let QReferenced= external_table('PQR')
| where Region == 'France' and Status == "Completed"
| project STId, Region, Status,RequestId;


let Regionpsllls = cluster("cp.ws.kusto.windows.net").database("pslll").pslll
| where State == "Active" and pslllType == "Region"
| project pslllId, pslllName = Name, pslll_Reg = RegionName;

let pslllServices = cluster("cp.ws.kusto.windows.net").database("pslll").PFL
| where ProductType == "Service"
| project pslllId, SOId;

let pslll_Reg_Serv = Regionpsllls
| join kind=inner pslllServices on pslllId
| project pslll_Reg, pslllName, SOId;

// Join onboarded with pslll
let Onboardedpslll = onboarded
| join kind=inner pslll_Reg_Serv on $left.STId == $right.SOId;

// Join region assigned with pslll
let regAsspslll = regAss
| join kind=inner pslll_Reg_Serv on $left.STId == $right.SOId;

// Join execution approved with pslll
let exeApprpslll = exeAppr
| join kind=inner pslll_Reg_Serv on ($left.STId == $right.SOId and $left.Region == $right.pslll_Reg);

//join quota refernced with pslll
let QReferencedpslll = QReferenced
| join kind=inner pslll_Reg_Serv on ($left.STId == $right.SOId and $left.Region == $right.pslll_Reg);


// Combine using inner joins (only psllls present in all three sets)
Onboardedpslll
| join kind=inner regAsspslll on pslll_Reg, pslllName
| join kind=inner exeApprpslll on pslll_Reg, pslllName
| join kind=inner QReferencedpslll on pslll_Reg, pslllName
| project pslll_Reg, pslllName ( i want many more cols to project)

1 ACCEPTED SOLUTION
v-tejrama
Community Support
Community Support

Hi @Sania-F,

 

The error you’re hitting is happening because the query does too much heavy lifting in the join stage, especially across two clusters. When multiple large tables are joined without reducing the data first, Kusto tries to expand everything in memory, which is what leads to the runaway query limit. The safest approach is to shrink each dataset to just the unique keys you actually need before joining, and build your final lookup in a single, optimized step. It also helps to materialize the cross-cluster table once so Kusto doesn’t reload it repeatedly, and to use join strategies like innerunique and broadcast so the engine doesn’t expand row combinations unnecessarily.

 

Another important point is to delay projecting many columns until the very end  projecting too many fields during joins increases memory pressure and can trigger this same failure. If you restructure the query to first summarize on STId or STId Region where needed, then intersect those key sets, and only then join once to your pslll dimension table, you’ll avoid memory spikes and get reliable results even across clusters. This pattern is well-aligned with Kusto best practices for large joins and should resolve the issue without needing further tuning. Let me know if you want help reviewing the final query shape, but this direction will get you past the limit safely.

 

Best Regards,
Tejaswi.
Community Support

View solution in original post

4 REPLIES 4
v-tejrama
Community Support
Community Support

Hi @Sania-F,

 

The error you’re hitting is happening because the query does too much heavy lifting in the join stage, especially across two clusters. When multiple large tables are joined without reducing the data first, Kusto tries to expand everything in memory, which is what leads to the runaway query limit. The safest approach is to shrink each dataset to just the unique keys you actually need before joining, and build your final lookup in a single, optimized step. It also helps to materialize the cross-cluster table once so Kusto doesn’t reload it repeatedly, and to use join strategies like innerunique and broadcast so the engine doesn’t expand row combinations unnecessarily.

 

Another important point is to delay projecting many columns until the very end  projecting too many fields during joins increases memory pressure and can trigger this same failure. If you restructure the query to first summarize on STId or STId Region where needed, then intersect those key sets, and only then join once to your pslll dimension table, you’ll avoid memory spikes and get reliable results even across clusters. This pattern is well-aligned with Kusto best practices for large joins and should resolve the issue without needing further tuning. Let me know if you want help reviewing the final query shape, but this direction will get you past the limit safely.

 

Best Regards,
Tejaswi.
Community Support

Hi @Sania-F ,

 

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

Thank you.

Hi @Sania-F ,

 

I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.

 

Thank you.

tayloramy
Community Champion
Community Champion

Hi @Sania-F

 

Your query is too large. See Runaway queries - Kusto | Microsoft Learn for optimization 

 

Here's some tips: 

  • Filter, project, and distinct before joining.

  • Build a small list of keys first (SOId), then do a single join back to the dimension.

  • Use materialize() to avoid re-evaluating the same subqueries.

  • Use join kind=innerunique for semi-joins, and apply join hints:

    • If the right side is small: join hint.strategy=broadcast.

    • If both sides are big: join hint.shufflekey=SOId.

 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

 

Helpful resources

Announcements
November Fabric Update Carousel

Fabric Monthly Update - November 2025

Check out the November 2025 Fabric update to learn about new features.

Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

Real Time Intelligence in a Day

Real-Time Intelligence in a Day—Free Training

Turn streaming data into instant insights with Microsoft Fabric. Learn to connect live sources, visualize in seconds, and use Copilot + AI for smarter decisions.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.