The error “Evaluation ran out of memory” (or “System.OutOfMemoryException”) occurs when Excel’s Power Query Mashup Engine attempts to merge two or more large database tables locally on your computer rather than letting Microsoft SQL Server handle the join. When query folding breaks, or when a merge is configured between mismatched data sources, Power Query downloads millions of uncompressed records into your local workstation RAM to execute a hash join. Once memory consumption exceeds the process limit—typically 2 GB on 32-bit Excel—the entire evaluation terminates.
Quick Answer
To fix “Evaluation ran out of memory” when joining massive SQL tables, perform the join on the SQL server using a database view or an explicit SQL statement (
SELECT ... FROM TableA JOIN TableB ON ...). If merging within Power Query, remove unnecessary columns before merging, ensure both tables come from the same database instance to preserve query folding, and switch to 64-bit Excel.
Why Joins Exhaust Workstation Memory
When you execute a join in Power Query using the Merge Queries button (Table.NestedJoin), the engine evaluates whether the join can be translated into a native SQL INNER JOIN or LEFT JOIN.
If the join folds to SQL Server:
- The database engine executes the operation using indexed join columns.
- The server’s high-speed memory and storage engines handle intermediate buffers.
- Only the final, filtered result set travels over the network to Excel.
If the join cannot fold to SQL Server:
- The Mashup Engine (
Microsoft.Mashup.Container.NetFX45.exe) attempts a local client-side join. - It loads the entire right-hand table into an in-memory hash table.
- It streams the left-hand table row by row, comparing keys locally.
- If either table contains millions of rows or dozens of wide text columns, local RAM fills rapidly until the container crashes.
For a broader look at server and driver performance constraints, consult Managing SQL Query Stability: Fixing Timeouts and Resource Exhaustion..
Step-by-Step Fixes
Method 1: Push the Join to the Database (Native SQL or View)
The most reliable way to prevent memory exhaustion is forcing the SQL Server engine to perform the join before Power Query touches the data.
- In Excel, go to Data > Get Data > From Database > From SQL Server Database.
- Enter your Server and Database.
- Expand Advanced options.
- In the SQL statement box, write an explicit join that returns only the required fields:
SELECT o.OrderID, o.OrderDate, o.CustomerID, c.CustomerName, c.Region FROM dbo.Orders AS o INNER JOIN dbo.Customers AS c ON o.CustomerID = c.CustomerID WHERE o.OrderDate >= '2025-01-01'; - Click OK and load the result.
By writing the join directly in SQL, you eliminate the client-side hash table, cutting memory usage from several gigabytes to a fraction of a megabyte.
Method 2: Eliminate Columns Before Merging
If you must use the Power Query graphical interface, reduce the memory footprint by stripping out unused columns prior to the merge step.
- Open your query in the Power Query Editor.
- In the query for Table A, select only the columns required for analysis and the foreign key.
- Click Home > Remove Other Columns (
Table.SelectColumns). - Repeat this exact process for Table B, keeping only the primary key and the specific columns you intend to extract.
- Perform the Merge Queries step only after both tables have been trimmed.
Carrying unneeded text descriptions, timestamps, or raw XML payloads into a join increases memory overhead exponentially.
Method 3: Diagnose and Prevent Cartesian Products
An accidental many-to-many relationship causes row counts to multiply uncontrollably, rapidly consuming all available memory.
- In SQL Server Management Studio or Power Query, verify key uniqueness on the lookup table:
SELECT CustomerID, COUNT(*) FROM dbo.Customers GROUP BY CustomerID HAVING COUNT(*) > 1; - If duplicate keys exist in what should be a dimension table, a
LEFT OUTER JOINwill duplicate every matching row in your fact table. - Remove duplicates or group the dimension table by key before executing the merge.
To troubleshoot why Power Query stops pushing join steps back to the database, see Troubleshooting “Query Folding” breaks: Why your SQL is running slow in Excel..
Hardware and Process Escalation
If your query is properly folded or written in native SQL, but memory errors persist:
- Check Office Bitness: Confirm whether you are running 32-bit Excel (File > Account > About Excel). 32-bit processes are hard-capped at 2 GB of virtual address space. Upgrading to 64-bit Excel allows Power Query to access all available physical system RAM. Learn more in “Excel ran out of resources while attempting to calculate”: Understanding 2GB vs. Large Address Aware limits..
- Evaluation Planning Crashes: If the engine crashes before reading data rows while building the query execution tree, review Troubleshooting “Out of Memory” during the SQL “Fold-to-Data-Source” phase..
- Worksheet Capacity Limits: If the joined result returns tens of millions of rows, load the query directly into the Power Pivot Data Model instead of an Excel worksheet table. For grid overflow limits, see Fixing “There isn’t enough memory to complete this action” in large datasets..