How to Set Up Incremental Refresh in Power BI
To set up incremental refresh in Power BI, create two date-range parameters named RangeStart and RangeEnd in Power Query, apply a date filter on your fact table using those parameters, then define the incremental refresh policy in the model settings, specifying how much historical data to keep and how much recent data to refresh on each run. Publish the report, and Power BI will only reload the recent, changing partitions instead of the entire table on every scheduled refresh.
Set up incremental refresh in Power BI to only reload recent data on each refresh, cutting refresh times drastically for large, growing datasets.
Incremental refresh solves a problem every growing dataset eventually runs into: a full refresh that used to take five minutes now takes two hours, because Power BI reloads every single historical row every time, even though only the last few days actually changed.
Why full refreshes stop scaling
By default, a scheduled refresh in Power BI reloads the entire table from the source, no matter how much of that data is unchanged. For a transactional table with a few hundred thousand rows, that is fine. For a table with tens of millions of rows spanning several years, reloading everything daily wastes gateway capacity, source database load, and refresh time, and it increases the chance of the refresh timing out altogether. Incremental refresh fixes this by splitting the table into partitions based on date ranges and only reprocessing the partitions that could realistically have changed.
How the partitioning actually works
Once configured, Power BI stores your fact table as a series of date-based partitions behind the scenes, invisible to report authors and end users. A policy of “archive 5 years, refresh last 10 days” means five years of history sit in stable partitions that are never touched again after their initial load, while a rolling 10-day window gets requeried against the source on every scheduled refresh. This is why the very first refresh after you enable incremental refresh takes just as long as before: Power BI has to build every historical partition once. Every refresh after that is fast, because it only touches the small recent window.
Detect data changes for an extra speed boost
If your source system reliably updates a timestamp column whenever a row changes, the Detect data changes option lets Power BI skip a partition entirely if nothing in it has actually been modified since the last refresh, rather than always requerying the full recent window. This is particularly effective for source tables that are mostly append-only with occasional late corrections, since most days will have zero changes to the older part of the refresh window.
Where the gateway fits in
If your fact table lives in an on-premises database, incremental refresh queries still travel through your Power BI gateway on every scheduled run, just against a much smaller date range each time. This is one of the most common fixes for gateway timeout errors on large datasets: instead of asking the gateway to pull years of data through a single query, incremental refresh asks it for ten days at a time.
Combining incremental refresh with a good data model
Incremental refresh works best on genuinely large fact tables with a reliable date column, typically ones backing time-series reporting like sales, transactions, or sensor readings. It is not a substitute for good data modelling; a poorly structured model with unnecessary columns and unoptimised relationships will still refresh slowly even with partitioning. See our article on how to make Power BI reports faster for the broader set of performance techniques incremental refresh sits alongside.
Our tip: Start with a conservative refresh window, such as the last 10 days, even if you think 3 days would be enough. Late-arriving data or source corrections that show up a week after the fact are extremely common, and a slightly wider window catches them automatically instead of requiring a manual full refresh.
Frequently asked questions
Does incremental refresh work without Power BI Premium?
The incremental refresh policy itself can be configured and tested in Power BI Desktop on any licence tier, but to actually schedule and run incremental refreshes in the Power BI Service, the workspace must sit on Premium capacity, Premium Per User, or Fabric capacity. On a shared Pro workspace, the dataset will fall back to a full refresh instead of using the partitioned behaviour.
Why do I need both RangeStart and RangeEnd, and can I name them differently?
Power BI specifically looks for two parameters named RangeStart and RangeEnd, both of Date/Time type, to detect that a table is eligible for incremental refresh. If you use different names, the Incremental refresh option will not appear for that table at all. The names are case-sensitive and must match exactly.
What happens to historical data outside the refresh window?
Data outside the incremental refresh window, but within the archive window, is not reloaded on each refresh; it stays as a stored partition inside the dataset. Only the partitions within the smaller refresh window (for example the last 10 days) get requeried against the source each time. Data older than the archive window is dropped entirely from the dataset unless you explicitly extend the archive period.
Can incremental refresh work with DirectQuery?
Yes, through hybrid tables. You can configure a table so recent data uses DirectQuery for real-time results while older, historical data is cached in Import mode through the incremental refresh partitions. This combines fast query performance on live recent data with the storage efficiency of Import mode for the historical archive.