Forum Discussion

mkj1213's avatar
mkj1213
Icon for Advocate II rankAdvocate II
4 months ago
Solved

PPU vs Fabric license memory limits - Resource Governance Error

I had one of the semantic model which was initially hosted on a pro workspace, where the incremntal refresh is enabled on that model. Recently the semantic size model had exceeded the 1 GB limit, and i needed to change the type of the workspace as the reduction of the size of the semantic model to less than 1 GB was unsucessful. 

 

In the company we had the option of converting the workspace to a PPU workspace before and recently we can also host it on our F8 capacity.
Initially we went with the first option (PPU Workspace) where the refresh goes smoothly and are completed in about 15 mintues.

Moving the workspace to the F8 capacity is  causing an error:

Resource Governance: This operation was canceled because there wasn't enough memory to finish running it. Either reduce the memory footprint of your dataset by doing things such as limiting the amount of imported data, or if using Power BI Premium, increase the memory of the Premium capacity where this dataset is hosted. More details: consumed memory 0 MB, memory limit 3072 MB, database size before command execution 3496 MB. See https://go.microsoft.com/fwlink/?linkid=2159753 to learn more.

As the error suggest the memory limit of F8 is 3072 MB, even when the large semantic model is enabled at the level of the workspace.   

My two questions are:

Why would my data model which has a size of about 1.2 GB, and is set to incremental refresh is consuming around 3 times its size in memory?

what is the memory limit of the PPU license? 

  • Short answer:
    - PPU works because it has a much larger model memory allowance.
    - F8 fails because its memory limit is around 3 GB and your model is already around 3.5 GB in memory before refresh.
    - The 1.2 GB size you see is not the same as the memory required during refresh.
    - Incremental refresh reduces processing, but it does not eliminate refresh memory overhead.

    The key detail is this part of the error:
    Database size before command execution 3496 MB
    memory limit 3072 MB

     

    So even though the PBIX/model may look like ~1.2 GB, the model’s in-memory footprint on the capacity is around 3.5 GB before the refresh command starts. That is already above the F8 memory limit shown in the error.

     

    This is why it works in PPU but fails on F8.

     

    A few important points:
    1. Model size is not the same as PBIX file size
    Power BI models are compressed on disk/in the PBIX. During refresh and query execution, the in-memory footprint can be much larger due to VertiPaq structures, dictionaries, relationships, partitions, caches, and temporary refresh structures.

    2. Refresh needs extra memory
    During refresh, Power BI does not just overwrite the existing model in place. It needs memory for the existing model plus the new/processed data and temporary structures. So a model that is “only” around 1.2 GB compressed can require multiple times that amount during refresh.

     

    3. Incremental refresh helps, but it does not remove refresh memory requirements
    Incremental refresh reduces the amount of data being processed, but the semantic model still needs enough memory for the existing model, the refreshed partitions, metadata, dictionaries, and processing overhead.

     

    4. Large semantic model storage format does not bypass the F8 memory limit
    It helps with storage/loading behavior, but the model and refresh operation are still governed by the capacity’s memory limits.

     

    For PPU, Microsoft documents the model size limit as 100 GB. However, the documentation also notes that this is an upper bound and that memory must still be reserved for operations such as refreshes and queries. So the practical limit can be lower depending on refresh/query memory requirements.

     

    In your case, the F8 capacity is likely simply too small for this model’s refresh memory footprint. The next practical test would be F16 or F32, but based on the error, F16 may still be tight if refresh overhead grows. I would also use DAX Studio / VertiPaq Analyzer to identify high-memory columns, high-cardinality columns, unnecessary columns, and calculated columns.

     

     

    References:
    https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-per-user-faq
    https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/troubleshoot-xml-analysis-endpoint

     

     

    Best regards,
    Solutions Architect · Microsoft Fabric Specialist · Parchitect

    💡Did my response help you? Clicking Kudos is a small gesture that goes a long way, it encourages contributors and helps the community thrive!
    ✔️Did I answer your question? Please mark my post as a Solution, it helps others find the answer faster.

     

3 Replies

  • Short answer:
    - PPU works because it has a much larger model memory allowance.
    - F8 fails because its memory limit is around 3 GB and your model is already around 3.5 GB in memory before refresh.
    - The 1.2 GB size you see is not the same as the memory required during refresh.
    - Incremental refresh reduces processing, but it does not eliminate refresh memory overhead.

    The key detail is this part of the error:
    Database size before command execution 3496 MB
    memory limit 3072 MB

     

    So even though the PBIX/model may look like ~1.2 GB, the model’s in-memory footprint on the capacity is around 3.5 GB before the refresh command starts. That is already above the F8 memory limit shown in the error.

     

    This is why it works in PPU but fails on F8.

     

    A few important points:
    1. Model size is not the same as PBIX file size
    Power BI models are compressed on disk/in the PBIX. During refresh and query execution, the in-memory footprint can be much larger due to VertiPaq structures, dictionaries, relationships, partitions, caches, and temporary refresh structures.

    2. Refresh needs extra memory
    During refresh, Power BI does not just overwrite the existing model in place. It needs memory for the existing model plus the new/processed data and temporary structures. So a model that is “only” around 1.2 GB compressed can require multiple times that amount during refresh.

     

    3. Incremental refresh helps, but it does not remove refresh memory requirements
    Incremental refresh reduces the amount of data being processed, but the semantic model still needs enough memory for the existing model, the refreshed partitions, metadata, dictionaries, and processing overhead.

     

    4. Large semantic model storage format does not bypass the F8 memory limit
    It helps with storage/loading behavior, but the model and refresh operation are still governed by the capacity’s memory limits.

     

    For PPU, Microsoft documents the model size limit as 100 GB. However, the documentation also notes that this is an upper bound and that memory must still be reserved for operations such as refreshes and queries. So the practical limit can be lower depending on refresh/query memory requirements.

     

    In your case, the F8 capacity is likely simply too small for this model’s refresh memory footprint. The next practical test would be F16 or F32, but based on the error, F16 may still be tight if refresh overhead grows. I would also use DAX Studio / VertiPaq Analyzer to identify high-memory columns, high-cardinality columns, unnecessary columns, and calculated columns.

     

     

    References:
    https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-per-user-faq
    https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/troubleshoot-xml-analysis-endpoint

     

     

    Best regards,
    Solutions Architect · Microsoft Fabric Specialist · Parchitect

    💡Did my response help you? Clicking Kudos is a small gesture that goes a long way, it encourages contributors and helps the community thrive!
    ✔️Did I answer your question? Please mark my post as a Solution, it helps others find the answer faster.

     

    • mkj1213's avatar
      mkj1213
      Icon for Advocate II rankAdvocate II

      Thanks for your reply, the other option that i am considering is to to redesign the semantic model using the medallion architecture where i will be moving the storage from the semantic model to a more suitable storage. 

  • trivedisunita's avatar
    trivedisunita
    Icon for Continued Contributor rankContinued Contributor

    Hi mkj1213 

    Thanks for sharing.

    The 1.2 GB you see is the compressed resting size of the model stored in VertiPaq. During refresh, VertiPaq build new partitions while keeping the old ones in memory until commit. This overlap can temporarily double or triple memory usage.

     

    Incremental refresh impact: Even with incremental refresh, multiple partitions may be processed at once. Historical partitions remain loaded, so peak memory usage is higher than the base model size.

    Extra overhead: Calculated columns, relationships, and high‑cardinality data increase memory footprint during processing. That’s why a 1.2 GB model can spike to ~3.5 GB in memory during refresh — it’s expected behavior documented by Microsoft.

     

    Premium Per User (PPU) supports datasets up to 100 GB in size.

    Refresh operations can run up to 48 times per day.

     

    Unlike Pro (1 GB limit) or smaller Premium capacities (like F8 with 3 GB memory), PPU provides a much larger allowance and does not enforce the same strict per‑capacity memory ceiling.

     

    That’s why your refresh completes smoothly in PPU but fails in F8 , PPU can handle the temporary 3× memory spike, while F8’s hard 3 GB limit blocks it.https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-large-models? 

    For PPU License - https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-per-user-faq? 

     

    If this reply helped you to solve your query please mark it as a solution.

     

    Thank you

    Sunita