Incremental refresh lets the Power BI service reload only the most recent slice of a large table, such as the last few days, and keep older data in place. You set it up in Power BI Desktop by creating two Date/Time parameters named RangeStart and RangeEnd, filtering the table's date column with them, and defining a refresh policy on the table. After you publish, the service splits the table into partitions and refreshes only the recent ones.

Why use incremental refresh

A normal refresh reloads every row of every table. For a fact table with years of history, most of that work reloads data that has not changed. Incremental refresh changes that:

• Refreshes finish faster, because only recent partitions are queried.

• The source database does less work on each refresh.

• Refreshes are less likely to hit the refresh time limit.

• The model can hold more history without making each refresh longer.

Scheduled refresh is still a schedule. Incremental refresh makes each run cheaper. It does not make the data real time, unless you add the optional DirectQuery partition described below.

Requirements for incremental refresh

• A date column to filter on. The table needs a column of type date/time, or an integer date key in the form yyyymmdd.

• Two parameters with exact names.RangeStart and RangeEnd are reserved and case-sensitive, and both must be of type Date/Time.

• A source that can filter by date. Relational sources such as SQL Server, Azure SQL and Azure Synapse work best. Other sources can work if the date filter can be passed to them.

• Query folding for the filter step. The filter should run in the source. If it does not fold, Power BI downloads every row and filters locally, which defeats the purpose.

• One source for the table. All partitions of the table must query the same data source.

Incremental refresh works on Power BI Pro. The real-time DirectQuery partition needs Premium, Premium Per User or Embedded. See our Import vs DirectQuery comparison for what DirectQuery changes.

Step-by-step guide: how to set up incremental refresh

Before you start, pick the table (usually your largest fact table) and the date column that decides which rows are new. An order date or transaction date is typical.

Step 1

In Power BI Desktop, select Transform data to open Power Query Editor. On the Home tab, select Manage Parameters > New Parameter.

Power Query Editor > Home > Manage Parameters > New Parameter.

Step 2

Create a parameter named RangeStart, set Type to Date/Time, and give it a current value. Then create RangeEnd the same way.

The Manage Parameters dialog. Both parameters must be Date/Time, with these exact names.

Choose values that cover a small, recent period, for example two days. In Desktop they only limit how much data loads while you build. After you publish, the service replaces them with the values the policy needs.

Step 3

Filter the table's date column with the two parameters. Use greater than or equal to RangeStart and strictly less than RangeEnd. If both ends were inclusive, a row that falls exactly on a boundary would load into two partitions.

With a date/time column, the step looks like this:

let
    Source = Sql.Database("myserver.database.windows.net", "SalesDW"),
    Sales = Source{[Schema = "dbo", Item = "FactSales"]}[Data],
    FilteredRows = Table.SelectRows(Sales, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    FilteredRows

If the date column is an integer key such as 20260115, convert the parameters to the same form:

FilteredRows = Table.SelectRows(
    Sales,
    each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart, [Format = "yyyyMMdd"]))
        and [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd, [Format = "yyyyMMdd"]))
)

Put the filter as early as possible, right after the source step, so it folds into the source query. Select Close & Apply.

Step 4

In Report view or Table view, right-click the table in the Data pane and select Incremental refresh. The Incremental refresh and real-time data dialog opens.

The Incremental refresh and real-time data dialog. The bar at the bottom shows the archived, incremental and real-time periods.

Set the policy:

1. Turn on Incrementally refresh this table.

2. Set Archive data starting: how much history to keep. In the example, 5 years.

3. Set Incrementally refresh data starting: the period reloaded on every refresh. In the example, 3 days.

4. Optionally turn on Only refresh complete days, which leaves out the current, incomplete day.

5. Optionally turn on Detect data changes and pick a last-modified column. Power BI then skips periods whose maximum value in that column has not changed.

6. Optionally turn on Get the latest data in real time with DirectQuery. This adds a DirectQuery partition after the refresh period and needs Premium, PPU or Embedded.

Select Apply, then publish the report to the Power BI service.

Step 5

In the service, open the semantic model's settings and set up Scheduled refresh. Run the first refresh manually so you can watch it. It loads all history and creates the partitions, so it takes much longer than later refreshes.

Semantic model settings > Scheduled refresh in the Power BI service.

The policy uses the current date at refresh time, in UTC unless you set a time zone for the refresh. To show readers when the last refresh ran, add a last refresh date to the report.

Limitations of incremental refresh in Power BI

• You cannot download the .pbix after publishing. Keep the Desktop file under version control.

• Republishing from Desktop replaces the partitions. The next refresh reloads all history. On Premium or Fabric capacity, tools such as the ALM Toolkit can deploy metadata changes without that reload.

• Refresh time limits still apply. A refresh on shared capacity (Pro) stops after two hours, and on Premium after five hours. Incremental refresh makes hitting the limit less likely but does not remove it.

• Non-folding sources are slow. If the date filter cannot run in the source, every row is downloaded on every refresh.

• The same parameters for every table. If several tables have policies, they all use the same RangeStart and RangeEnd, though each can have its own periods.

If refreshes are still slow after this, our slow report troubleshooting guide covers the other causes. Dataflows support incremental refresh too; see how and when to use dataflows.

FAQs

What is the difference between Power BI full refresh and incremental refresh?

A full refresh reloads every row of every table in the model. An incremental refresh reloads only the partitions inside the refresh period, such as the last three days, and leaves older partitions untouched. The first refresh after publishing is effectively a full load, because it creates all partitions.

How many refreshes are allowed in Power BI per day?

A semantic model on shared capacity, which is what Power BI Pro uses, can have up to 8 scheduled refreshes a day. On Premium, Premium Per User or Fabric capacity, you can schedule up to 48. Refreshes you start manually with Refresh now do not count toward the limit of 8.

Sources

• Configure incremental refresh and real-time data for Power BI semantic models - Microsoft Learn

• Data refresh in Power BI - Microsoft Learn