Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!View all the Fabric Data Days sessions on demand. View schedule
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)
Solved! Go to Solution.
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,
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.
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.
Check out the November 2025 Fabric update to learn about new features.
Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!
Turn streaming data into instant insights with Microsoft Fabric. Learn to connect live sources, visualize in seconds, and use Copilot + AI for smarter decisions.