Power BI Server Memory Issues

[ElenaC]

Hello,

We are experiencing an issue in Microsoft Power BI where visuals intermittently fail to load with the following error:

“Error fetching data for this visual. The operation was throttled because the server is under memory pressure.”

This occurs in a report built on a recently rebuilt data model. The model has been redesigned from scratch, and all relationships now originate from a centralized source. Despite this, the issue persists, especially when interacting with visuals that involve multiple joins and aggregations.

Details:

• Error: Memory throttling / server under memory pressure

• Impact: Visuals fail to render intermittently

• Dataset: Medium-to-large size with multiple relationships

• Environment: Power BI Service (shared capacity)

• Frequency: Occurs during normal usage, not only peak times

We would appreciate your support in:

• Identifying the root cause of the memory pressure

• Verifying whether this is related to capacity limits or model design

• Recommending optimizations or configuration changes

Please let us know if additional diagnostic information (Activity ID, timestamps, dataset details) is required.

Thank you in advance for your assistance.

[Olufemi7]

Hello @ElenaC, 

This is Power BI Service shared capacity memory throttling.

Likely cause
High-cardinality columns
Complex or bi-directional relationships
DAX iterators over large fact tables
Heavy visuals (large matrices, many joins)
Shared capacity memory contention
How to confirm
Performance Analyzer for slow visuals
Capacity Metrics app for memory spikes
Check if issue happens only in Service
Fix order
Use strict star schema
Remove bi-directional relationships
Replace text keys with integer keys
Pre-aggregate large fact tables
Reduce iterator-heavy DAX
Simplify large visuals
Microsoft docs
Shared capacity limits
The Fabric throttling policy 
Visual query limits
Set visual query limits in Power BI Desktop 
Performance Analyzer
Use Performance Analyzer to examine report performance 

If it works in Desktop but fails in Service, shared capacity pressure is a key factor.

[cengizhanarslan]

Step 1) Check for bidirectional relationships. Every bidirectional relationship can double the filter propagation paths the engine must evaluate. Set all relationships to single direction unless bidirectional is strictly required.

Step 2) Remove unused columns. Every column loaded into the model consumes memory. Open the model in Desktop, go to Model view, and remove any column not used in a measure, relationship, slicer, or visual. Measure Killer is an excellent external tool for this.

Step 3) Check cardinality of text columns. High-cardinality text columns (URLs, free-text descriptions, GUIDs stored as strings) are the single biggest source of unnecessary memory consumption. Replace with integer keys where possible.

Step 4) Avoid calculated columns that replicate fact table data. Move logic to measures instead — measures are computed on demand and do not consume persistent memory.

Step 5) Add pre-aggregated tables. For large fact tables with common aggregation patterns (daily totals, monthly summaries, category rollups), create pre-aggregated summary tables in upstream in SQL and load those alongside the grain-level fact table. Visuals that only need aggregated data query the summary table directly, bypassing the need to scan and aggregate millions of raw rows at query time. This is one of the most impactful memory optimizations available on shared capacity.

Step 6) Simplify complex measures. Measures with nested FILTER, CALCULATE chains, or CROSSJOIN operations generate large intermediate tables during evaluation. Simplify where possible.

[Kagiyama_yutaka]

I think the core issue is the shared‑cap query mem cap being tripped by a tiny row‑expansion burst… if u drop one high‑card text col or pre‑agg the fact a bit it clears fast… and if it still hangs, test that visual alone to confirm the spill path.

[krishnakanth240]

Hi @ElenaC 

Error is due to memory limits in shared capacity rather than a bug. Model and visuals are generating heavy queries from multiple joins, high cardinality, complex DAX which exceed per-query memory threshold causing the throttling.So can you try optimizing the model with star schema, reducing cardinality, avoiding bi-directional filters, simplifying measures and limit data volume.

For consistent performance with larger models moving to Premium or Fabric capacity is often the more reliable solution

[ibarrau]

Hi. If you have really optimize the model doing a great star schema and other downsizing data model practices and it's still like that, it might be a measure. That message is something I often see at tables or matrix. If you are using more than one measure, try removing one by one and adding again checking if the problem is a single one or two of them. A heavy measure can break a visual. Once you find it, you can copy that here or ask IA or read about DAX optimization.

I hope that helps,