If you connect Power Query to a SQL database and a refresh takes forever, check query folding first.
What folding is
Folding means Power Query translates your steps into a single SQL query, so the database does the work and sends back only the result. Without it, Power Query may download far more data and process it on your machine.
So a filter that folds might return 50,000 rows from a table of 50 million. If it doesn’t fold, a lot more of that table may have to travel to your laptop first.
How to check
Right-click a step in Applied Steps. If View Native Query is available, that step is generally folding, and you can read the SQL it generates. If it’s greyed out, folding has probably stopped by that point.
Treat this as a strong hint, not a guarantee, because some connectors don’t show it even when folding is happening.
Order your steps deliberately
Once one step breaks folding, everything after it runs locally, so the order matters. What folds depends on the connector and the data source, so treat these lists as a starting point. Excel and CSV files don’t fold at all.
Usually fold (put these first):
- Removing columns
- Filtering rows
- Basic joins between tables in the same database
- Grouping and summing
Often break folding (put these later):
- Custom columns using M functions with no SQL equivalent
- Adding an index column
- Merging with a table from a different source, such as an Excel file
So filter and remove columns first, and leave the custom logic for the end.
When you need complex logic
If the transformation is complicated, write it as SQL and let Power Query simply read the result. Use a view on the database if you can. If you paste a custom SQL statement into the connection dialog, be aware that later steps often won’t fold on top of it, so include your filters in the SQL itself.
The goal is the same either way: let the database do what it’s good at, and send your laptop as little as possible.