Native queries have their own complexities, and by default break any ability for Power Query to fold on top of it (more below) kzfaq.info/get/bejne/er2Sm5qp1ZacnGQ.html It also relies on having a developer know SQL and SQL optimization techniques, which are all built into the query folding engine. Like with most things though, it depends. :)

It's the magic sauce of Power Query :). Transformations are translated from M (Power Query) to the source, and passed back for the source to transform (faster). Rather than Power BI downloading the unprocessed data, and doing it itself (slower). You can easily get a 5, 10, 20+ times performance increase when the source database does most the work. A quick google search would give you some helpful results like below on why it makes queries faster. www.reddit.com/r/PowerBI/comments/14strbb/what_does_folding_in_query_folding_means/ Also, to note,. Incremental refresh is explicitly advised NOT to use without folding. Because without folding you download the entire data before filtering to the relative period. Which is why when folding can't be confirmed with the engine, it gives a big warning that advises not to use incremental refresh. More below on that as well. learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview

@@HavensConsulting Thank you for your explanation. Are you saying if I write "Select ProductID from Sales" myself in the Source dialog Advanced options, Power Query still loads all the data first, then executes my Select statement?

@@1yyymmmddd native queries (e.g. writing custom SQL Code in the statement box) will actually break any ability to query fold. So generally advised to not use that. It's advised to use the Power query actions to choose your columns, filter your rows, do your transformations. etc. More info about native query limitations below learn.microsoft.com/en-us/power-query/native-database-query