Incremental refresh

Hi powerbidev123 ,

No, Power BI doesn't write the Power Query transformations back to the source database.
What can happen is that, through query folding, Power BI pushes supported operations down to SQL Server so they are executed there during refresh. Your RangeStart and RangeEnd filter is usually compatible with query folding. 

You can verify whether it's folding by checking View Native Query.

ref- https://learn.microsoft.com/en-us/power-bi/guidance/power-query-folding 

If you need the transformation logic to live in the database, you'd need to create it as a view, stored procedure, or similar database object.

Hope this helps!

Hello powerbidev123,

If you are asking regarding Power BI Incremental Refresh, the short answer is NO. The applied steps in Power Query are not written back to the SQL database. But, the Sql.Database folding is ON by default, and your current steps should already be folding fine.

How to check if a step is folding:
Right-click on the step (e.g. "Filtered Rows") in the Applied Steps pane --> "View Native Query".

• If it's enabled (not greyed out), Power Query is generating SQL and pushing it to the database, you can even see the exact query it built.
• If it's greyed out, that step (or an earlier one) broke folding, and everything from that point runs locally in Power Query's engine instead.

For your specific query:

• Sql.Database(...) --> folds (it's the connection itself)
• Navigation (Source{[Schema=..., Item=...]}) --> folds, becomes the base SELECT * FROM table
• Table.SelectRows with a simple comparison like [report_week] >= RangeStart and [report_week] < RangeEnd --> folds into a WHERE clause

So this should already be pushing down as something like:

SELECT * FROM xxxxxx.xxxxxxx
WHERE report_week >= @RangeStart AND report_week < @RangeEnd

Things that will silently break folding if you add more steps later:

• Custom M functions or each logic with complex conditionals
• Table.AddColumn using functions not translatable to SQL (e.g., certain text/date functions, or M-only functions)
• Merging with a non-foldable source, or with a step that already broke folding
• Table.Buffer / List.Buffer (these force materialization intentionally)
• Changing column types in a way the connector can't map to SQL types
• Grouping/pivoting after a non-foldable step

After every step you add, spot-check "View Native Query" to catch the exact point where folding breaks. It's much easier to fix one step than to hunt through the whole query later.

Thanks,
If you found this solution helpful, please consider giving it a Like👍 and marking it as Accepted Solution✔. This helps improve visibility for others who may be encountering/facing same questions/issues.