Forum Discussion
Error: Reached the maximum resources
Hey ahmedshalabyy12 ,
Thanks for the information that helps a lot. Power BI Desktop uses your local machine’s resources, and there is no fixed memory limit like in the Service.
Power BI Desktop does NOT have a hard memory cap per query instead Power BI Desktop uses as much RAM as your machine can provide and its engine can consume tens of gigabytes of memory if available. The only strict limit is the 225-second timeout, which applies when “Query Limit Simulation” is enabled. So if you do not want you can not ignore the timeout. If you don’t enable simulation, Desktop still has practical limits because the VertiPaq engine and the formula engine allocate memory in chunks and will terminate queries that exceed internal thresholds. There’s no official published “hard limit” for Desktop without simulation, but it’s generally bounded by the engine’s design, not your full RAM.
To measure and control the heaviness of your query:
-
Enable Query Limit Simulation:
Go to File > Options > Current File > Report Settings > Query Limit Simulations. -
DAX Studio:
DAX Studio → Connect to your PBIX → Enable Server Timings → Run the visual → Check:- VertiPaq scans
- Materialization size
- Storage Engine vs Formula Engine time
- Memory callbacks
Best Practices to Avoid Issues
- Reduce cardinality like avoid large text columns or biggest performance killer.
- Mark date table as a date table.
- Remove unused columns.
- Use aggregations instead of detailed tables.
- Optimize DAX (avoid iterating over large tables inside CALCULATE).
- If you need to test extreme scenarios, consider breaking visuals into smaller filtered subsets.
-
Use proper star schema.
-
Avoid Crossjoin-like logic in DAX.
Best Regards,
Nasif Azam-
Hey ahmedshalabyy12 ,
This error means that a single visual/query is using more memory (or time) than your capacity allows, not just that the dataset is big.
1) What is the actual limit?
For visual queries, Power BI applies time + memory limits per query, depending on the capacity where your report is hosted: Set visual query limits in Power BI Desktop
- Both Shared and Premium capacity having 225 seconds of timeout
-
Shared / Pro capacity memory per query is ~1 GB (1,048,576 KB)
-
Premium / PPU / Fabric capacity memory per query is ~10 GB (10,485,760 KB)
If a visual sends a query that exceeds those limits, you get the “Resources Exceeded: The query has exceeded the available resources” message.
These limits are separate from the dataset size limit. PowerBI Pro Dataset & Workspace Size Limitations Restrictions
2) How can I measure this so I don’t exceed it?
There is not very simple, because the limit is based on memory usage while the query runs, which depends on your model design and DAX. However, you can get an idea in a few ways:
-
Simulate the service limits in Desktop:
-
In Power BI Desktop: File > Options and settings > Options > Current file > Report settings > Query limit simulations
-
Choose Shared capacity or Premium.
-
Desktop will then stop queries using the same timeout/memory rules as the service and show you the limit values. Set visual query limits in Power BI Desktop
-
-
If you’re on Premium/Fabric capacity
-
Admins can use the capacity metrics app and capacity settings to monitor and tune memory usage per query/capacity. Configure workloads in a Premium capacity
-
3) How to avoid hitting the limit: To reduce the chance of this error, you can:
-
Filter visuals more: Reduce the date range or apply slicers so visuals don’t try to load “all history” at once.
-
Avoid very large tables/matrices: Big flat tables with many columns + many rows are heavy. Table/Matrix visuals only show up to about 30,000 rows anyway, so aim to show summaries (Top N, per month, per category) instead of everything. The query has exceeded the available resources
-
Optimize your data model: Use a star schema, remove unused columns, reduce high-cardinality columns (long text, detailed IDs). Avoid “expensive” DAX patterns such as:
-
Filtering on entire large tables inside CALCULATE
-
Measures that never return BLANK()
-
-
Consider Premium/Fabric capacity: If you’re regularly hitting limits Premium/PPU/Fabric give you more RAM per query and support larger datasets, and capacity admins have more control over memory settings.
Best Regards,
Nasif Azam
Thank you Nasif_Azam danextian for the answer appreciate your efforts, however I was asking about the desktop limits not the service .
I have 64gb of memory so I think my pc supposed to handle all the queries; therefore, I wanted to know the limit of the query, ignoring the 225 seconds case .
From the query limit simulations, have you tried selecting "no query limits"?. Also, even if you have 64 gigs, you must consider other processes that run in the background. It also boils down the query you're trying to run and the size of the visual you're trying to display it on.
Hey ahmedshalabyy12 ,
Thanks for the information that helps a lot. Power BI Desktop uses your local machine’s resources, and there is no fixed memory limit like in the Service.
Power BI Desktop does NOT have a hard memory cap per query instead Power BI Desktop uses as much RAM as your machine can provide and its engine can consume tens of gigabytes of memory if available. The only strict limit is the 225-second timeout, which applies when “Query Limit Simulation” is enabled. So if you do not want you can not ignore the timeout. If you don’t enable simulation, Desktop still has practical limits because the VertiPaq engine and the formula engine allocate memory in chunks and will terminate queries that exceed internal thresholds. There’s no official published “hard limit” for Desktop without simulation, but it’s generally bounded by the engine’s design, not your full RAM.
To measure and control the heaviness of your query:
-
Enable Query Limit Simulation:
Go to File > Options > Current File > Report Settings > Query Limit Simulations. -
DAX Studio:
DAX Studio → Connect to your PBIX → Enable Server Timings → Run the visual → Check:- VertiPaq scans
- Materialization size
- Storage Engine vs Formula Engine time
- Memory callbacks
Best Practices to Avoid Issues
- Reduce cardinality like avoid large text columns or biggest performance killer.
- Mark date table as a date table.
- Remove unused columns.
- Use aggregations instead of detailed tables.
- Optimize DAX (avoid iterating over large tables inside CALCULATE).
- If you need to test extreme scenarios, consider breaking visuals into smaller filtered subsets.
-
Use proper star schema.
-
Avoid Crossjoin-like logic in DAX.
Best Regards,
Nasif Azam-
