Incremental refresh tells Power BI to reload only recent data (say, the last 10 days) on each refresh and keep older data as it is. It works on Power BI Pro, Premium Per User and Premium or Fabric capacity. To set it up in Power BI Desktop you create two Date/Time parameters named exactly RangeStart and RangeEnd, filter your date column with them, then right-click the table and define an incremental refresh policy. For it to work well, your data source has to support query folding, which in practice means a database such as SQL Server or Azure SQL.
When it's worth doing
Set up incremental refresh when a table is big and mostly historical: sales transactions, invoice lines, time entries, sensor readings. Signs you need it:
- Refresh takes a long time and keeps getting longer.
- Refresh is getting close to the 2-hour limit on Pro or the 5-hour limit on Premium.
- Refresh fails with memory errors. (See memory limit exceeded errors.)
- You'd like to refresh more often but can't afford the load on the source system.
Don't bother for small lookup tables such as customers or products. Refresh those in full.
Before you start: check query folding
Incremental refresh only saves time if Power BI can push the date filter down to the source, so the source returns just the rows in range. That's called query folding. If the query doesn't fold, Power BI pulls every row and filters them itself, which defeats the purpose and can make refresh slower than before.
Folding works reliably on relational databases such as SQL Server, Azure SQL, Azure Synapse and Oracle. It usually doesn't work on Excel files, CSVs or SharePoint lists. In Power Query you can right-click the last step of your query: if View Native Query is available, the query is folding. Some sources fold without showing it, so treat this as a quick check rather than proof. Power BI also shows a warning in the incremental refresh dialog when it can't confirm folding.
Keep your query simple before the filter. Steps like merging with a non-database source, adding an index column, or some custom functions can stop folding. Put the date filter as early as you can.
Step 1: create the RangeStart and RangeEnd parameters
- In Power BI Desktop, select Transform data on the Home ribbon.
- In Power Query, select Manage Parameters, then New Parameter.
- Create a parameter named
RangeStart, type Date/Time, with a current value such as the first day of last month. - Create a second parameter named
RangeEnd, type Date/Time, with a current value such as the first day of this month.
The names are case-sensitive and must be exactly RangeStart and RangeEnd. The type must be Date/Time, not Date. The current values only control how much data loads into Desktop while you work, so keep the range small.
Step 2: filter the table
- In Power Query, select the date column in your large table.
- Open its filter menu and select Date Filters, then Custom Filter.
- Set the first condition to "is after or equal to" and choose the RangeStart parameter.
- Set the second condition to "is before" and choose the RangeEnd parameter.
- Select Close and Apply.
The equals sign must be on one side only. If you use "after or equal to" RangeStart and "before or equal to" RangeEnd, rows that fall exactly on a boundary load twice and your totals come out wrong.
If your date column is a whole number in yyyymmdd form (common in data warehouses), you'll need a small function to convert RangeStart and RangeEnd to that format inside the filter. Microsoft's documentation has the exact code.
Step 3: define the refresh policy
- In Power BI Desktop, right-click the table in the Data pane and select Incremental refresh.
- Turn on Incrementally refresh this table.
- Set Archive data starting to how much history to keep, for example 5 years.
- Set Incrementally refresh data starting to how much recent data to reload each time, for example 10 days.
- Choose any optional settings (below), then select Apply.
The optional settings:
- Only refresh complete days. Skips today until the day is over. Useful when today's data is still arriving and you don't want half-day totals.
- Detect data changes. Only refreshes days where a "last updated" column has changed. Use a different column from the one you filtered on. It won't catch rows that were deleted outright.
- Get the latest data in real time with DirectQuery. Adds a live partition for data newer than the last refresh. This needs Premium Per User, a Premium or Fabric capacity, or Embedded. It isn't available on Pro.
Pick the refresh window with some care. It should cover how far back your data can still change. If invoices can be edited for 30 days after they're issued, a 10-day window will leave stale numbers.
Step 4: publish and run the first refresh
- Save and publish to the Power BI service.
- If the model is large and you're on Premium Per User or a capacity, turn on Large semantic model storage format in the model's settings before the first refresh.
- Run the first refresh by hand with Refresh now and watch the refresh history.
The first refresh loads all the history you asked to keep, so it takes much longer than later ones. After that, each refresh only reloads the recent window. Then set up your schedule under Refresh, then Schedule refresh.
Things that catch people out
- You can't download the file back. Once incremental refresh has run in the service, you can't download the .pbix from the service. Keep your own copy of the file.
- Republishing wipes the history. Publishing the model again from Desktop replaces the partitions, and the next refresh reloads all the history. On Premium or a capacity, there are tools that can change the model without republishing. On Pro, plan changes so you don't have to republish often.
- Time zone. Power BI works out "today" in UTC unless you set a time zone in the refresh schedule. If you're in the US and refresh in the evening, UTC may already be tomorrow. Set the time zone.
- One source per table. All the partitions for a table have to come from a single data source.
- Desktop shows only a slice. In Desktop you only see the rows between your RangeStart and RangeEnd values. That's expected. The full history lives in the service.
When to call someone
Incremental refresh is very doable on your own if your data is in SQL Server or Azure SQL and the query is simple. It's worth getting help when the source doesn't fold, when refresh is already failing and you need it working fast, when you're weighing whether PPU or a capacity would be simpler, or when the model has to change often and republishing keeps wiping the history.
For one model that won't refresh, our $299 Power BI fix covers it, and you don't pay if we can't fix it. For a bigger rework of how your data loads, see Power BI advisory. If you're still choosing a license, read Pro vs Premium Per User vs Fabric first.
Sources: Microsoft Learn, Incremental refresh overview, Configure incremental refresh, Data refresh in Power BI.