Stumbling blocks in Power Query usually trace back to a single cause: the logic isn't built for the engine. The user who posted this problem built a library of nested if statements and merge-based custom columns, then branched the query to reduce column count from the twenties down to seven or eight. That sounds like a sensible optimization. It didn't work. The data still refuses to load. The frustration is real, and it points to a deeper misunderstanding of how Power Query processes work.
The engine evaluates row by row, and nested ifs are a sequential gate. Every row that fails the first test must pass through the second, then the third, and so on. When those conditions reference merged tables, the engine has to fetch and compare data at each step. The result is a multiplicative slowdown that buffering cannot fix. Buffering a table that is already being queried conditionally for every row is like adding a faster pump to a clogged pipe. The bottleneck is the logic, not the memory. The user's library of logic may feel organized, but it is organizing inefficiency.
What this means in practical terms is that the approach needs to shift from procedural to set-based thinking. Instead of writing a custom column that says "if this, then merge that, else if that, then merge this other thing," build a single lookup table that contains all possible outcomes. Merge that table once. A single merge operation, even on a larger table, will almost always outperform multiple conditional merges because Power Query can parallelize the join. The same principle applies to the nested ifs: replace them with a mapping table and a single merge. The user already has the logic assembled in a library, which means half the work is done. The missing step is flattening that logic into a structure the engine can consume efficiently.
The concrete takeaway is this: stop asking Power Query to decide what to do for each row. Give it a complete map of what to do for every possible case, then let it perform one join. That single change will likely cut load time from minutes to seconds. The user is not wrong to seek optimization. They are wrong to optimize the wrong variable. Shift the logic from row-level decision trees to column-level lookups, and the workflow will unlock.