Forum Discussion
How to exclude large historical table from refresh in Power BI?
Hi everyone!
I wanted to share how I finally resolved the issue I posted about earlier regarding excluding a large historical table from refresh in Power BI.🧩 The problem recap:
We had a large fact table (~200M rows, 93 columns), and incremental refresh failed during full dataset refresh due to timeout and memory limits – partitions weren’t being created.
We attempted a Hot & Cold Data approach by splitting into historical and current tables in Power Query and appending them, but even with “Include in refresh” disabled for historical, Power BI still queried it during refresh.
Using DAX UNION to combine both tables increased dataset size and hurt performance due to additional in-memory tables and complex measures.
✅ What worked:
We switched to custom partitioning using Tabular Editor and SQL Server Management Studio (SSMS).
I created one partition per year manually and gradually loaded data year by year.
This approach allowed us to:
Successfully configure incremental refresh.
Avoid timeouts.
Reduce memory pressure during refresh.
🚀 Bonus:
Once all partitions were added and processed, incremental refresh ran smoothly.
This method avoided unnecessary reloading of historical data during refresh and ensured performance remained stable.
I hope this helps someone facing a similar challenge. Feel free to ask if you’d like more technical details! 😊
Super UserHi katushka_enko ,
Firstly, disabling refresh on a query only works if that query is not subsequently referenced later. The fact you are appending your current and historical tables means that your history table is referenced and, therefore, forced to refresh regardless of this setting. You could try using this setting but keeping the current/historical fact tables separate (i.e. no subsequent references to historical), but this may cause you further complications with time intelligence etc. Or you could potentially use this method but then UNION the two tables in the model using DAX, but you're adding quite a significant processing step by doing this.
For what you're trying to achieve here, and the sheer number of rows (and growing) that you're dealing with, I think you will need to use either incremental refresh and/or custom partitions. If your historical data is 100% cold and has absolutely 0% chance of needing to be refreshed then you could get away with just using incremental refresh, but I think a 'belt and braces' approach using both would be prudent (what happens when current data needs to be archived to cold storage, for example?).
Using custom partitions will allow you to load your incremental refresh history in bite-size chunks, as well as only refreshing selected chunks going forward.
There's plenty of resources online about how to set up custom partitions but, I'll warn you, it's not for the faint-hearted!
Pete
Hi Pete,
Thanks for your response!
We actually used Incremental Refresh, and it worked well initially. However, the problem arose when we had to make changes to the dataset – each time we modified it, we had to refresh the entire dataset from scratch. Since the dataset size and number of records increased significantly, Incremental Refresh started failing consistently, throwing timeout errors. Eventually, the capacity got overloaded and stopped working altogether.
We also tried managing partitions via XMLA, but that required loading both the historical and current tables into the model and then combining them using DAX UNION, which didn’t seem optimal in terms of performance.
A few questions regarding your recommendations:
1) Do you have any recommendations for handling Incremental Refresh in cases where dataset size is too large, and full refresh becomes unmanageable?
2) Regarding custom partitions – are there any hidden pitfalls or challenges we should be aware of before implementing this approach?