memory error doesnt seem right

Hi db042190​,

Each Fabric Capacity has a limited amount of memory for model refreshes. An F4 has a limit of 3GB, and that is shared across all models, so if you have multiple models refreshing at the same time, they will share that 3GB. 
The memory limits for each capacity sku are here: What is Power BI Premium? - Microsoft Fabric | Microsoft Learn

See this blog post from Microsoft for more details: Fabric Capacity Scaling and Power BI - What happens when Power BI model guardrails are exceeded? | Microsoft Fabric Community

 

Hi db042190​ ,

The error is accurate, and the reason the usage dashboard looks clean is that it can't show you what failed here.

CUs and storage are not the constraint. CUs measure CPU time, and the Storage tab is OneLake bytes on disk — an import model's in-memory footprint isn't in either one. Memory for semantic models is governed separately by Analysis Services resource governance, and the Fabric Capacity Metrics app doesn't expose those metrics at all. So you can be at 1% utilization with zero throttling and still get this.

The numbers in your error tells that:

- Database size before command execution: 1589 MB

- Memory limit granted: 1482 MB

- Consumed: 1484 MB

A full refresh needs roughly 2-3x the model's in-memory footprint, because the old copy stays resident while the new one is built, plus recalc on top. So a ~1.6 GB model wants somewhere around 3-5 GB of headroom and isn't getting close.

On the SKU side: F2, F4 and F8 all share the same 3 GB per-model ceiling, so bumping to F8 buys you nothing. F16 is the next real step at 5 GB. Also worth knowing that the 3 GB figure is an upper bound on model size, not a refresh budget — the docs note memory has to be reserved for refresh and query operations, so the usable number is lower. Fabric allocates dynamically too, which is why you got an odd 1482 MB rather than something round.

As for why it worked before and not today: the model grew past the tipping point, something else was resident on the capacity at that moment, or someone had a report open against the same model while the refresh ran. Query + refresh on one model stacks well past 2x.

What I'd do, in order:

1. Run VertiPaq Analyzer (DAX Studio or Tabular Editor) against the model via the XMLA endpoint. You'll almost always find one or two high-cardinality columns eating a third of the model. Datetime columns with seconds are the usual offender — split into date + time. Drop unused columns, and turn off auto date/time if it's on.

2. Move to incremental refresh, or drive partition-level refreshes through XMLA. The full-model refresh is what's killing you; one partition at a time keeps peak memory way down.

3. Check nothing else is querying the model during the refresh window.

4. Only look at F16 if optimization doesn't get you there. A 1.6 GB model is often 800 MB-1 GB after a proper cleanup, which sits comfortably inside F4.

One thing you can already cross off: at 1589 MB the model is above the 1 GB default, so Large semantic model storage format is clearly enabled.

If you want ongoing visibility into this, Workspace Monitoring captures AS engine events including memory, which is the gap the metrics app leaves.

Please mark this post as solution & let me know if this post helps you. Appreciate Kudos.