Forum Discussion
Semantic Model Refresh Fails with Memory Limit Error on F2 (Rolling 12-Month Full Load)
Hi everyone,
I’m facing an issue with a semantic model refresh failing due to memory limits on an F2 capacity.
I’m using Microsoft Fabric (F2 capacity, North Europe) with two workspaces (UAT and Production).
Parallel table loading is already disabled (set to 1).
The report contains a rolling 12-month window of data, always including the current month and going back to the same month in the previous year (for example, April 2025 – April 2026). Because historical data can change retroactively (for example, corrections in previous months), I currently run a full refresh of all 12 months on a daily basis. I have not implemented incremental refresh because I assumed that since any historical month can change, I would still need to refresh the entire dataset anyway.
However, every time I trigger a refresh in Fabric, it fails immediately with the following error:
Resource Governance: This operation was canceled because there wasn't enough memory to finish running it. Consumed memory 3559 MB, memory limit 3065 MB, database size before command execution 6 MB.
So it seems the model exceeds the available memory during processing.
I have a few questions:
- I have the same semantic model deployed in both UAT and Production workspaces on the same F2 capacity. Could this contribute to memory pressure during refresh? Would deleting the UAT version after deployment help?
- Is my assumption about incremental refresh correct? If historical data can change at any time, does that mean incremental refresh is not useful? Or is there a better approach (for example, refreshing only specific months that changed)?
- Apart from disabling parallel loading, what other options do I have to reduce peak memory usage during refresh on an F2 capacity?
Thanks in advance.
Hi drgenius
1.Is storage the issue
No, this is not a storage problem. 6 MB before execution means model is dropped & rebuilt during the refresh. Failure happens due to peak memory during processing and not the storage limits
2.Can Incremental Refresh still work if any month can change?
Yes, you don’t need full refresh where you can configure Incremental Refresh with rolling 12 months. For older corrections you can use Detect data changes based on modified date column
Even if any month can change, it doesn’t mean all months change every day
Failing is because full refresh = all partitions processed together. F2 limit = 3 GB per operation for a single semantic model of import mode. If the process hits ~3.5 GB then it fails immediately
Please go through these documentation for your reference.
Incremental refresh overview -https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview
Incremental refresh configuration - https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-configure
Incremental refresh troubleshoot - https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-troubleshoot
Large semantic models - https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-large-models
6 Replies
Hi drgenius,
I would also take a moment to thank Gabry , krishnakanth240 for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Regards,
Community Support Team.Hi drgenius,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We are always here to support you.
Regards,
Community Support Team.
Hi drgenius
1. UAT and Prod on same F2
Yes, they share the same memory. Can contribute to failures especially if refresh overlaps. Deleting UAT helps slightly but won’t fix peak memory during refresh
2.Incremental Refresh assumption
Not correct. You can use Incremental Refresh. Keep 12 month window. Refresh only last N months like 2–3 months or weeks based on your requirement.
3. How to reduce memory
Implement partitioning in Incremental Refresh which reduces model size, removing unused columns, pushing transformations to source, avoiding merges or calculated columns in Power Query, and using aggregation tables
krishnakanth240 Thanks for the response!
About UAT, I don’t refresh it daily, only when testing, so I don’t think it overlaps with prod refreshes.
One thing I’m wondering about (and I may be wrong), is there some kind of underlying storage or database where semantic models are persisted on the capacity? I’m asking because the error shows “database size before command execution: 6 MB” which means the dataset is essentially empty before each attempt. Could it be that this storage is full or constrained in some way on F2, causing the refresh to fail even before loading real data?
Regarding Incremental Refresh, in my case historical months do get corrected, and not just the last 2-3 months. Corrections can happen for any month within the 12-month window. So a fixed refresh window of 2-3 months wouldn’t be safe for me. Is there a way to handle this with incremental refresh, or does this scenario essentially require a full reload every time?Hi drgenius
1.Is storage the issue
No, this is not a storage problem. 6 MB before execution means model is dropped & rebuilt during the refresh. Failure happens due to peak memory during processing and not the storage limits
2.Can Incremental Refresh still work if any month can change?
Yes, you don’t need full refresh where you can configure Incremental Refresh with rolling 12 months. For older corrections you can use Detect data changes based on modified date column
Even if any month can change, it doesn’t mean all months change every day
Failing is because full refresh = all partitions processed together. F2 limit = 3 GB per operation for a single semantic model of import mode. If the process hits ~3.5 GB then it fails immediately
Please go through these documentation for your reference.
Incremental refresh overview -https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview
Incremental refresh configuration - https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-configure
Incremental refresh troubleshoot - https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-troubleshoot
Large semantic models - https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-large-models
Hey drgenius ,
1) I think the memory consumption is calculated on a per-operation limit enforced by Fabric's resource governance While having UAT and Production refresh at the exact same time could cause capacity-level throttling, your specific error means that a single refresh of your Production dataset requires ~3.5 GB of RAM to complete. So deleting the UAT environment will not solve your isse and will not change anything
Documentation2) Your assumption makes logical sens, if any month can change, standard incremental refresh won't capture retro-active corrections. You can take a look on a feature called detect data changes.
3) You could think about using direct lake instead of impor mode.
Otherwise you need to reduce the model footprint, by elminating unused columns or reducing cardinality
Hope this help you 😉
