Forum Discussion
Power BI Server Memory Issues
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.
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.
8 Replies
Hi ElenaC
What I would recommend doing is in Power BI Desktop to go into the memory settings and set it for the same memory size allocation is what you get if you are running Power BI Pro and see if the report renders. If you then change the setting to a higher value and the report runs successfully then you know that there is something in your model that is causing the issue. I would then recommend. Using the best practices as a sum of highlights and above to see how to simplify your model into a style schema until you can get it to work successfully with the memory setting for the Power BI Pro. And once that is done, your report should then run successfully.
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,
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.
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
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.
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 performanceIf it works in Desktop but fails in Service, shared capacity pressure is a key factor.
Hi ElenaC,
Thank you for reaching out to Microsoft Fabric Community.
Thank you Kagiyama_yutaka, cengizhanarslan, Olufemi7 and GilbertQ for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
