Power BI incremental refresh for large tables

Incremental refresh splits a table into partitions by a date range. On refresh, Power BI processes only the partitions that fall inside the refresh window instead of reloading the whole table. Older partitions stay in the model untouched and are eventually merged or removed as the window rolls forward.

It does not reduce the size of the model. It reduces the work and time needed to refresh. The first refresh still loads the full archive, so plan for a longer initial run and a source that can handle it.

The source query must filter on two parameters, RangeStart and RangeEnd, and both must be DateTime. The filter must be on a date or datetime column in the source, and the table must be published before the service can create partitions.

The archive window is how far back the model keeps data. The refresh window is how far back each refresh reprocesses. A common pattern is several years of archive and a short refresh window that covers late-arriving records.

Make the refresh window longer than the longest expected delay. If an invoice can arrive three days after its transaction date, a two-day window will miss corrections. If the source backfills a month, the window must be at least a month.

As an illustration, three years of daily rows is about 1,095 days. A ten-day refresh window covers roughly 1 percent of that history, so the saving comes from the rows read, not from a smaller model.

Incremental refresh relies on the source doing the date filtering. In Power Query, select the filter step and use View Native Query. If the option is unavailable, the step is not folding and the refresh may download more data than expected.

Folding breaks when a step uses a custom function, an unsupported transformation, or a calculated column before the filter. Move the date filter as early as possible, keep the source query simple, and avoid changing column types before the filter if that blocks folding.

For file-based sources and some services, folding is not available. The query can still be configured, but the mashup engine may apply the filter after retrieving all rows, which defeats the purpose. Measure the actual refresh duration rather than assuming the window is doing the work.

Watch refresh duration and failure messages for the first few runs. A refresh that suddenly processes all partitions usually points to a broken fold, a parameter change, or a full-refresh request. Republishing the model from Desktop resets partitions and data, so treat a republish as a full deployment rather than a routine update.

Small tables do not benefit. A dimension with a few thousand rows reloads faster than the overhead of partitioning. Tables without a reliable date column, or sources that cannot filter efficiently, are also poor candidates.

If the requirement is near-real-time data, incremental refresh is the wrong tool; it is still a scheduled batch. Use DirectQuery or a real-time partition when freshness matters more than model performance, and accept the trade-off in query speed and source load.