Power BI incremental refresh: reload only what changed
Power BI incremental refresh reloads only the newest slice of a large table instead of the whole history. A normal refresh throws away every row and fetches them all again. That wastes time when last year's data never changes. With a refresh policy, the service keeps old periods as they are and updates recent ones. This guide shows how the feature works, what it needs and where it goes wrong.
- RangeStart and RangeEnd
- Query folding required
- Shorter refresh windows
Last updated
How does Power BI incremental refresh work?
The feature rests on two date parameters named RangeStart and RangeEnd. In Power Query you filter the table's date column between them. Then you define a policy on the table in Power BI Desktop.
A policy has two parts. First, it states how much history to keep, for example several years. Second, it states how much to refresh each time, for example the last few days.
After you publish, the service takes over. It splits the table into partitions by period and fills in the parameters for each one. On later refreshes it reloads only the recent partitions. So old periods stay put, and the run finishes far sooner.

What the feature needs to work well
Six conditions decide whether a policy helps or quietly does nothing.
A date column
The table needs a date or date-time column that marks when each row belongs.
Query folding
The date filter must reach the source as part of its query, so only needed rows travel.
A capable source
Relational databases fold well, while files and many web APIs do not.
Stable history
Old periods should stay unchanged, because the service will not look at them again.
Matching data types
Parameters are date-time values, which then need a column of a compatible type.
Patience on first run
The first refresh after publishing loads all history, so it takes the longest.
What does query folding do for a refresh policy?
Folding means Power Query translates your steps into the source's own language. A date filter becomes a condition in the database query. Therefore the database returns only the rows for one partition.
Without folding, the picture reverses. Power Query asks for every row and filters afterwards. So each partition pulls the whole table, and the refresh can become slower than before.
Desktop warns when it cannot confirm folding. You can also check by viewing the native query for the filter step. If a step breaks folding, move it after the date filter or push it into a view at the source. That small change often rescues the policy. Slow models beyond refresh are covered under Power BI performance tuning.
Common Power BI incremental refresh mistakes
Watch for these six errors, since each one undoes the benefit.
- Filtering dates after a step that breaks folding
- Using both greater-or-equal and less-or-equal
- Refreshing a window shorter than late changes
- Expecting Desktop to load the full history
- Republishing and wiping the partitions
- Applying it to small tables that refresh quickly
Setting up Power BI incremental refresh in four steps
These four steps follow Microsoft's documented order.
Create the parameters
First add RangeStart and RangeEnd as date-time parameters, with a short range for development.
Filter the table
Then filter the date column between the two parameters, inclusive on one side only.
Define the policy
Next set how much history to store and how much to refresh, and confirm folding.
Publish and refresh
Finally publish to the service and run the first refresh, which builds every partition.
Questions about refresh policies in Power BI
Does incremental refresh in Power BI need Premium?
No. Microsoft supports the basic feature for models in workspaces with Pro licenses, as well as Premium Per User and capacities. Some related options, such as getting the latest data in real time with DirectQuery, need Premium or Fabric capacity. Check the current licensing notes before designing a policy.
What does Power BI do when old rows change after the refresh window?
They are missed by default, since the service reloads only recent partitions. There are two answers. You can widen the refresh window to cover late changes. Or you can use the detect data changes option, which checks a last-updated column and refreshes a partition only when that value moved.
Can Power BI refresh one old period by hand?
Yes, on workspaces that expose the XMLA endpoint for writing. A tool that connects through that endpoint can refresh a single partition. This helps after a correction to one past month. On other workspaces, the practical route is a full refresh, which reloads all history again.
Why is my Desktop file so small after setup?
Desktop loads only the rows between the parameter values you set for development. That is by design, so authors work with a light file. The service then loads the full range defined in the policy. For the same reason, do not download and republish carelessly, because a changed model can force a complete reload.
Can you set this up on our slow model?
Yes. Long refreshes are a common sign that a policy is missing. One of our consultants checks folding, partitions and the source, then sets a policy and measures the result. Power BI Agency is part of Sataware Technologies and works in your own tenant. The first step is a free assessment, then a written, fixed scope.
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.