← All articles
5 min read

Power BI Incremental Refresh Explained: Faster Refreshes, Less Data, Better Reports

Tired of slow Power BI refreshes on large datasets? Incremental refresh is the fix. Learn how it works, how to set it up with RangeStart and RangeEnd, and the mistakes to avoid.

Server rack in a data center with blue lighting

If your Power BI refreshes are slow, time out, or hammer your database every night — incremental refresh is the fix. Instead of re-importing your entire dataset on every run, it only loads the data that’s actually changed.

The result: a table with 200 million rows that took 45 minutes to refresh can complete in under 5 minutes.


The Problem With Full Refreshes

Every scheduled refresh re-imports everything — all your historical data — just to capture the few thousand new rows added that day. This means:

  • Long refresh times that risk hitting the 2-hour Pro limit
  • Heavy load on your source database every night
  • Frequent failures due to long-running connections

Incremental refresh splits your table into date-based partitions. Historical data sits untouched. Only the recent window gets re-imported on each run.


How It Works

Power BI uses two reserved parameters — RangeStart and RangeEnd — to filter which rows get loaded into each partition. You define a policy with two settings:

  • Archive period — how many years of history to keep (e.g. 3 years)
  • Refresh window — how far back each refresh re-imports (e.g. last 3 days)

Once published, the Power BI Service handles all partition creation and management automatically. You never have to touch it again.


Step-by-Step Setup

1. Create the Parameters

In Power Query Editor, go to Manage Parameters → New Parameter and create two parameters:

NameTypeExample Value
RangeStartDate/Time01/01/2025 00:00:00
RangeEndDate/Time03/01/2025 00:00:00

The names are case-sensitive — they must be exactly RangeStart and RangeEnd.

2. Filter Your Table

In your table’s query, add filter steps that reference both parameters:

let
    Source = Sql.Database("yourserver", "yourdb"),
    FactSales = Source{[Schema="dbo", Item="FactSales"]}[Data],
    #"Filtered Start" = Table.SelectRows(FactSales, each [OrderDate] >= RangeStart),
    #"Filtered End"   = Table.SelectRows(#"Filtered Start", each [OrderDate] < RangeEnd)
in
    #"Filtered End"

Don’t use the standard “Custom Filter” dropdown — it won’t reference the parameters correctly. Add the steps manually in the formula bar.

3. Define the Policy

In Report view, right-click your table in the Fields pane → Incremental refresh. Set your archive period and refresh window, then click Apply.

A sensible starting point for most businesses:

  • Archive: 3 Years
  • Refresh window: 7 Days (wider if source data can arrive late)

4. Publish and Run the First Refresh

Publish to Power BI Service as normal. The first refresh will be slow — Power BI is building all the historical partitions from scratch. Every refresh after that will only touch the recent window and complete much faster.


The One Thing That Can Break It — Query Folding

Incremental refresh only works efficiently if your Power Query filter is pushed down to the database as a SQL WHERE clause. This is called query folding.

If folding isn’t happening, Power BI downloads the entire table first and then filters it in memory — which defeats the whole purpose.

Quick check: Right-click a filter step in Power Query. If “View Native Query” is available, folding is working. If it’s greyed out, it isn’t.

Common folding-breakers: pivot/unpivot steps, merging queries, or custom functions that SQL can’t translate.


Pro vs Premium

FeatureProPremium
Incremental refresh
Refresh time limit2 hours5 hours
Real-time DirectQuery partition
Models over 1 GB

Even on a Pro licence, incremental refresh makes a significant difference for large tables.


Three Mistakes to Avoid

Wrong parameter names. rangeStart, Range_Start, or any other variation will silently break the policy. Must be RangeStart and RangeEnd.

Republishing from Desktop after go-live. This destroys all your partitions and historical data. Use the ALM Toolkit for schema changes after the initial publish.

Too narrow a refresh window. A 1-day window risks missing late-arriving data. When in doubt, go wider — 7 days costs very little extra refresh time.


Incremental refresh is one of those features that feels complex the first time but becomes second nature quickly. Once you’ve set it up, you’ll wonder how you ever managed without it.


Dealing with slow refreshes or a growing data model? Book a free consultation with the Nova Analytics team.

Need help with Power BI?

Book a free consultation with the Nova Analytics team — we'll sort it out together.

Book Free Consultation
← Back to all articles