Power Query transformations are displayed as a tidy list of steps, but the engine does not necessarily execute them one by one on the local machine. When a connector and transformation support it, Power Query can translate work into the source system’s native query language and let the source perform filtering, projection, aggregation, or joins. That optimization is query folding. The practical problem is that one transformation can change where the remaining work runs.
For PL-300 candidates, folding matters because it connects data preparation to refresh performance and DirectQuery behavior. A query that looks small in the editor can be expensive if it forces the source to return far more data than the model needs. The right troubleshooting question is not “which step is slow?” but “which engine is performing this step, and how much data crosses the boundary?”
Folding is an execution plan, not a visual property
The Applied Steps list describes logical transformations. Query folding describes how those transformations are evaluated. With a relational source, Power Query may combine several steps into one source query. With a file source such as CSV, there is no query engine to push work into, so the Power Query engine must perform the transformations itself.
That distinction is one reason a source inventory such as common data-analytics file types matters operationally. Two datasets with the same columns can have very different refresh characteristics depending on whether they come from a SQL engine, an API, or a file. The shape of the data is only half of the problem; the execution capabilities of the source are the other half.
Filtering early helps only when the filter can move upstream
A common recommendation is to filter rows as early as possible. The real benefit appears when the filter is folded to the source so unnecessary rows never cross the network boundary. If an earlier custom transformation breaks folding, moving a filter visually higher may still leave the Power Query engine processing a large source result.
This is why developers should inspect whether folding is still available after important steps. The goal is not to maximize a folding score. It is to keep expensive reduction operations close to the source when that source is better equipped to perform them.
Join order can have the same effect as filter order. A merge that folds to the source may let the database use indexes and reduce rows before transfer. The same merge performed after folding breaks can require Power Query to materialize both sides locally. Large refreshes should therefore test not only which transformations exist but the point in the sequence at which they are executed.
DirectQuery makes the folding boundary non-negotiable
In DirectQuery, report interactions generate queries that ultimately must be answered by the source. Power Query transformations therefore need to remain foldable so the model can translate requests into source operations. A transformation that requires local materialization contradicts the DirectQuery execution model.
The source itself also matters. A managed relational engine such as the one described in Azure SQL Database fundamentals can evaluate predicates, joins, and aggregations efficiently when the query is shaped well. Power BI cannot compensate for a source that lacks indexes, has poor statistics, or requires an unnecessarily complex query for every visual interaction.
DirectQuery also makes source concurrency visible. One slow visual can generate several source queries, and many users can issue them at once. Query folding is necessary but not sufficient; the source must be sized, indexed, and governed for interactive analytical traffic rather than only for its original operational workload.
Import mode still benefits from folding because refresh has a cost
Import models materialize data into the semantic model, so they are more tolerant of non-folding transformations. Tolerant does not mean free. If a relational source contains hundreds of millions of rows and the final model needs only a small filtered subset, losing folding can turn a short refresh into a large extraction followed by local processing.
The better design is to reduce data as early as the source can support, then let Power Query handle the transformations that truly belong in the mashup layer. This keeps refresh predictable and lowers pressure on gateways, network links, and local memory.
Gateway placement can turn a logically efficient query into an operational bottleneck. A folded query may still move a large result through an undersized gateway or a slow network link. Refresh design should include source execution time, network transfer, gateway resource use, and Power Query processing as separate measurements instead of assuming one metric explains the whole run.
A convenient custom step can create a hidden cliff
Some transformations cannot be translated to the source. A custom function, a source-specific limitation, or a step that changes the evaluation boundary can stop later operations from folding. The problem is not that non-folding steps are forbidden. The problem is that their cost can be invisible until the data volume grows.
A useful review asks what the data volume is at the point folding stops. If the query has already reduced the source to a small dataset, local work may be acceptable. If folding breaks before the major filters and joins, the same logical result may require far more transfer and processing.
Privacy levels and data-combination rules can also alter evaluation. When queries combine sources, the engine must respect isolation boundaries designed to prevent unintended data leakage. A transformation that is harmless with one source can behave differently when another source is introduced, which is why folding and privacy should be tested in the actual multi-source design.
Native queries can solve one problem while closing other options
Power Query can use native SQL for relational sources, which can be helpful when a transformation is easier or more efficient to express directly. That choice also changes the optimization boundary. Later folding is limited, and some features such as incremental refresh have constraints around native queries. The shortcut therefore needs an architectural reason, not just a preference for writing SQL.
The deeper lesson from SQL fundamentals is that query location matters. Logic can live in the source, a view, a native query, Power Query, or the semantic model. Each location changes ownership, testability, reuse, and performance. The best location is where the logic is most stable and observable.
Views are often a better long-term boundary than embedding complex native SQL inside a report-specific query. A governed view can be reused, tested, secured, and optimized by the data platform team. Native SQL inside Power Query can still be appropriate, but it should not become the only copy of business-critical transformation logic.
Folding and data quality can pull in different directions
Source systems are optimized for their own workloads, not necessarily for analytics semantics. A transformation that standardizes categories, handles malformed records, or enforces business rules may not fold cleanly. Moving all quality logic back to the source can improve refresh performance while making the source harder to govern or coupling analytics to an operational application.
This is where data-quality ownership matters. Teams need to decide which corrections belong in the source, which belong in a governed transformation layer, and which should cause the load to fail rather than silently change the data. Performance is one decision criterion, not the only one.
Incremental refresh makes the folding boundary especially important because range predicates need to reach the source to avoid full extraction. A seemingly unrelated transformation that prevents those filters from folding can destroy the performance assumption behind the incremental design. Teams should recheck folding whenever the query shape changes materially.
Troubleshooting should compare the native plan before and after a change
When refresh time jumps after a small edit, compare the query before and after the change. Look for the step where folding stops, the amount of source data being retrieved, and whether an operation moved from the source engine into the Power Query engine. That causal comparison is more reliable than randomly rearranging steps.
A good performance test uses realistic data volume and the same connectivity path as production. Desktop development on a small sample can hide gateway latency, source contention, and transformations whose cost grows nonlinearly.
Query Diagnostics and source-side monitoring provide complementary evidence. Power Query can show evaluation behavior while the database can show the actual statements, duration, scans, and resource use. Comparing both sides helps distinguish a folding problem from a source-plan problem or a gateway bottleneck.
A baseline is most useful when it records row counts and elapsed time at several points in the refresh, not just the final duration. That lets the team see whether a regression came from a larger source extract, slower gateway transfer, or more local transformation work. Without that evidence, folding investigations can turn into guesswork.
The best query is the one whose execution path is explainable
Query folding is valuable because it makes the source do work it can often perform efficiently. It becomes dangerous only when developers assume folding is automatic or permanent. Connector capabilities, transformation choices, storage mode, and source behavior all influence the plan.
A strong Power BI preparation process therefore connects the transformation layer to the model and reporting layer described in business intelligence architecture. If the team can explain which engine filters, joins, aggregates, and materializes the data, it can reason about refresh performance before a production incident forces the lesson.
Query folding should also be rechecked after connector, gateway, or source-version changes. A query that folded last year may behave differently after a connector update or a source feature change. Treat the execution plan as part of operational regression testing instead of assuming it is a permanent property of the M script.
