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! 😊
Hi BA_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?
Community SupportHi katushka_enko ,
Thank you for reaching out to us on the Microsoft Fabric Community Forum.
Instead of refreshing all partitions, configure incremental refresh to retain only the necessary historical data while limiting refreshes to recent partitions. For example, store up to five years of data but refresh only the last three months.
Rather than maintaining a single large dataset, break it into smaller datasets based on business logic (e.g., by year or region) and refresh them individually.
If using Power BI Premium, Hybrid Tables allow mixing Import mode (for Current) and DirectQuery (for Historical), reducing memory usage.
Custom partitions provide better control over refresh but require XMLA scripting and management. Here are potential pitfalls:
1.Even with partitioning, if the total dataset is too large, it can still hit capacity limits.
2.Requires using tools like SSMS, Tabular Editor, or Power BI REST APIs.
If this post was helpful, please give us Kudos and consider marking Accept as solution to assist other members in finding it more easily.