query has exceeded to available resources

This is a very common Power BI performance issue, especially with complex measures + table visual. Let’s break it down clearly and practically.

Why you’re getting this error?
“Query has exceeded the available resources” happens because:

• Your table visual evaluates measures row-by-row
• The 2 measures are very heavy (50–60 lines of DAX)
• Power BI runs those measures for every row + totals
• Result → memory/CPU limit exceeded

That’s why:

• With measures → error
• Without measures → visual loads

What to do (quick fixes)?

1. Move row-level logic out of measures
   • Duration, weekend diff, start–end time logic
     • Create Calculated Columns or Power Query columns
2. Simplify measures
   • Measures should only SUM / COUNT / AVERAGE
   • Avoid SUMX, FILTER, VALUES in table visuals
3. Split big measures
   • Break 1 large measure into multiple base measures
4. Reduce table columns
   • Remove unnecessary text/datetime columns
5. If DirectQuery
   • Push logic to source or switch fact table to Import

Always remember:

• Complex DAX + Table visual = performance issue
• Complex logic in columns, simple measures in tables

=================================================================
Did I answer your question? Mark my post as a solution! This will help others on the forum!

Appreciate your Kudos!!

Jaywant Thorat | MCT | Data Analytics Coach
LinkedIn: https://www.linkedin.com/in/jaywantthorat/
Join #MissionPowerBIBharat: https://tinyurl.com/JoinMissionPowerBIBharat
#MissionPowerBIBharat
LIVE with Jaywant Thorat

1) Model-level improvements 

These usually help a lot:

• Reduce cardinality:

  • don’t use long text keys in relationships (use integer surrogate keys)

  • split datetime into date (and maybe hour) if you don’t need full timestamp

• Ensure a proper star schema:

  • dimensions filter facts (single-direction)

  • avoid bi-directional unless absolutely needed

• Remove unused columns / reduce string columns in facts

2) Identify what’s slow 

Open DAX Studio → connect to the Desktop model → run:

• Server Timings

• Query Plan

Then refresh the slow visual in Power BI Desktop to capture the query.

What to look for:

• SE (Storage Engine) time high → model / relationships / cardinality / storage mode issue

• FE (Formula Engine) time high → DAX patterns, calc groups, iterators, context transitions

• # of Storage Engine queries very high → calc group causing measure re-evaluation many times

3) Create pre-aggregations at the source

If you can’t change the calculation logic, one of the most effective performance options is to reduce the amount of data the engine must scan by introducing pre-aggregated fact tables in the source (or Lakehouse/Warehouse) and using them in the model.

4) Avoid iterator functions

As a general rule, try to avoid iterator functions such as SUMX, FILTER, ADDCOLUMNS, RANKX on large tables whenever possible. These functions execute row by row in the Formula Engine, which is significantly slower than simple aggregations pushed to the Storage Engine. In models with calculation groups and matrix visuals, iterators can multiply the amount of work per cell and quickly lead to slow interactions or “Query has exceeded the available resources” errors.