Power BI incremental refresh can shorten recurring refreshes by partitioning a table and refreshing only the recent periods you configure. It does not make the first service refresh instantaneous: that refresh still has to process the historical period in your policy. The key prerequisite is query folding—the source should receive a bounded date query, rather than Power Query downloading the whole table and filtering it locally.
How incremental refresh speeds up recurring refreshes
Without incremental refresh, a routine import refresh may need to reload a table’s full history. With a policy, Power BI divides the table into time-based partitions. The policy defines how much history to retain and which recent periods to refresh; later refreshes can then avoid reprocessing unchanged older periods.
As an Amazon Associate I earn from qualifying purchases.
The initial refresh in the Power BI service is different: it processes the configured historical window. How long it takes depends on the volume and shape of the data, the source, the model, the capacity, and whether the date filter folds. Incremental refresh therefore reduces recurring work; it is not a guarantee of a fast first load or a specific percentage of time saved.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What to prepare before configuring a policy
Choose the date column and retention windows
Select the table’s date or date/time column that determines which period a row belongs to. Decide how much historical data the model must retain, then choose a smaller recent window to refresh routinely. The archive window controls the history kept; the refresh window controls how much recent data is revisited. Set these to match your reporting and data-correction needs rather than choosing arbitrary periods.
#1 Best Overall
Check data types and source behavior
- Create Power Query parameters named exactly
RangeStartandRangeEnd. Both must have the Date/Time data type. - Use a filtered column with a compatible Date/Time type and format. If the source uses an integer date key, Microsoft’s incremental-refresh guidance describes converting the parameter values to match the key while preserving folding; avoid casually converting the source key column if that breaks folding.
- Confirm that the source connector and the transformations in the query can fold. Query folding means Power Query translates the steps into a query that the source can execute, instead of retrieving all rows and applying the filter locally.
Microsoft’s Configure incremental refresh for Power BI semantic models guidance describes the Desktop preview as loading only data between the two parameters. That preview behavior does not guarantee that every published query folds or that the first service refresh will load only a small amount of history.
Configure the date filter and incremental refresh policy
- Create the parameters. In Power Query, create
RangeStartandRangeEndas Date/Time parameters. Use the exact spelling and capitalization so Power BI can recognize them. - Filter the table’s date column. Apply a lower bound of greater than or equal to
RangeStartand an upper bound of less thanRangeEnd. This half-open interval includes the start and excludes the end. - Verify a bounded test query. Set a short preview range and check that it returns the expected rows. If a small range still takes a long time or consumes substantial resources, treat that as a warning that the filter may not be folding.
- Set the policy in Power BI Desktop. Configure the amount of history to archive and the recent period to refresh for the table. If you enable change detection, select a separate date/time column that records when rows were last updated.
- Publish and refresh in the service. Publish the model, then run a manual refresh or wait for its scheduled refresh. The service applies the policy during refresh and manages the table’s partitions.
Why the filter must exclude the end value
Adjacent partitions share a boundary. Suppose one partition covers 2026-01-01 00:00 through, but not including, 2026-02-01 00:00, and the next starts at 2026-02-01 00:00. A row exactly at midnight on February 1 belongs only to the second partition when the filter uses >= RangeStart and < RangeEnd. If both ends use equality-inclusive comparisons, a boundary row could be included twice.
Validate folding before relying on the policy
Incremental refresh only helps if Power BI can restrict work to the intended date range at the source. If folding is lost earlier in the query, Power Query may have to retrieve far more data than the preview range suggests. Microsoft’s Query folding guidance in Power BI Desktop explains how Power Query translates supported transformations for source-side execution.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitches- Inspect Power Query’s folding indicators where available, and review the source-side query or query logs if your source exposes them.
- Test a narrow date range before publishing. An unexpectedly slow or resource-intensive test is a reason to investigate folding, not evidence that the policy will make a full scan efficient.
- Review each transformation before the filter as well as the filter itself. A step that cannot fold may prevent later steps from being sent to the source.
- After publishing, check refresh behavior and source workload. A successful refresh alone does not establish that the source received an efficient bounded query.
Microsoft’s Troubleshoot incremental refresh and real-time data guidance is useful when data types, folding, or hybrid-model behavior cause problems.
Choose options for detecting changes and serving fresh data
Change detection for periods without updates
The optional change-detection setting uses a tracking column—typically a last-updated timestamp or audit value—to determine whether a period has changed. Use a different column from the one that partitions the table. When the tracking value has not changed, Power BI can skip refreshing that period.
Change detection does not find hard-deleted rows: once a row is removed from the source, its former tracking value is no longer available to signal the deletion. A soft delete can be detected if the row remains in the source and its tracking value changes when it is marked deleted.
Import-only incremental refresh
For many models, the straightforward choice is an import table with a bounded refresh window. It suits reports where data can wait until the next scheduled or manual refresh, and it avoids querying the source for every report interaction.
Hybrid real-time tables
A hybrid table combines imported historical partitions with a DirectQuery partition for data newer than the import refresh window. The Desktop option described by Microsoft requires Premium capacity. DirectQuery can make recent source data available without waiting for the next import refresh, but report queries now depend on source responsiveness. Microsoft recommends setting related tables to Dual mode for performance. Visual caching can also mean a user does not see a source change until a visual queries again.
XMLA and advanced partition management
For eligible Premium models with XMLA read/write enabled, XMLA tools such as SSMS or Tabular Editor can support selective partition refreshes, staged initial loading, and advanced policy operations. These workflows are optional; a normal policy configured in Desktop does not require them. Staging can help when one initial historical load would exceed service or source limits, but it adds operational complexity. XMLA refresh operations have different limits from scheduled refresh, so check Microsoft’s current Advanced incremental refresh and real-time data with the XMLA endpoint in Power BI guidance before designing that workflow.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Decide which approach fits your model
| Approach | Freshness | What it requires | Main trade-off |
|---|---|---|---|
| Import-only incremental refresh | Updates on the next manual or scheduled refresh | A folding date filter and an incremental refresh policy | Recent source changes wait for the next refresh. |
| Hybrid real-time table | Can query newer data through DirectQuery | Premium capacity for the Desktop option, plus appropriate related-table storage modes | Report queries depend on the source; DirectQuery behavior and visual caching affect apparent freshness. |
| XMLA partition management | Depends on the partition operations you run | An eligible Premium model with XMLA read/write enabled and an operational tool or process | Offers advanced control but requires more setup and maintenance. |
Choose based on how fresh the report must be, whether the source supports folding, how much history the first load must process, what capacity and features are available, and whether your team can operate a hybrid or XMLA workflow.
Plan for the first load and service limits
The first service refresh still processes the configured historical period, so estimate its impact on both the source and the model before publishing. If the model is expected to exceed applicable model-size constraints, Microsoft advises enabling large-model storage format before the first service refresh. Consult current Power BI guidance for the relevant limits and configuration.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteMicrosoft’s troubleshooting guidance states scheduled-refresh time limits of two hours for Power BI Pro models on shared capacity and five hours for Premium-capacity models. These are service limits, not expected refresh durations or performance targets; verify current capacity and service limits before relying on them. If the initial historical load cannot finish within the available limits, an eligible XMLA-based staged load may be an option, but it is not required for ordinary incremental-refresh setup.
Common problems and what to check
- The service refresh is still slow: Check whether the date filter folds, whether the configured historical window is larger than necessary, and whether the source or capacity is the bottleneck.
- Rows appear in two adjacent periods: Use a half-open filter—greater than or equal to
RangeStart, less thanRangeEnd—rather than including both endpoints. - A short preview range is unexpectedly expensive: Investigate folding and query execution at the source before assuming the policy will limit the work.
- Changes or deletions are missing: Confirm that the refresh window includes the affected period. If using change detection, verify that the tracking column changes for updates; hard deletes are not detected by that mechanism.
- A hybrid report appears stale: Check whether the visual has queried again and account for visual caching, as well as source responsiveness and related-table storage modes.
Further Microsoft guidance
Microsoft Learn’s Manage semantic models in Power BI training module covers semantic-model management, including incremental refresh settings. The PL-300 Power BI Data Analyst certification is a broader learning path, not a prerequisite for configuring incremental refresh. For dataflows, Microsoft documents related behavior separately in Using incremental refresh with dataflows.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
