A "memory limit exceeded" error in Power BI means your semantic model (what Power BI used to call a dataset) needs more memory than your workspace allows, either while it refreshes or while a visual runs its query. The fix is almost always to make the model smaller: remove columns and rows you don't use, cut down high-cardinality columns, replace DAX calculated columns with Power Query columns, and turn off auto date/time. If the model is still too big after that, incremental refresh or a move to Premium Per User or a Fabric capacity is the next step.
What the error looks like
It shows up in a few forms. In the Power BI service you'll usually see one of these in the refresh history:
- "Query memory limit exceeded"
- "This operation was canceled because there wasn't enough memory to finish running it."
- An error code of 0xC13E0003, which Microsoft describes as a cancellation due to memory pressure
In Power BI Desktop the same problem can show up as a refresh that fails partway through, or a visual that spins and then errors out.
They all point to the same thing. The model, or the query a visual is asking the model to run, is bigger than the memory available to it.
Why it happens
Power BI keeps imported data in memory. It compresses that data well, but some things compress badly, and on a Power BI Pro license you're working inside hard limits.
Microsoft's documented limits: on shared capacity (a normal Pro workspace), a semantic model can't be larger than 1 GB, and a refresh can't process more than 10 GB of uncompressed data. Premium Per User and Fabric capacities raise those limits, but they still have a ceiling that depends on the license or capacity size. Microsoft also notes that part of that memory has to stay free for refreshes and queries, so the practical limit is lower than the headline number.
The models that hit the wall usually have one or more of these:
- Columns nobody uses. Every column you import takes memory, even if no report touches it.
- High-cardinality columns. Columns with lots of unique values (transaction IDs, timestamps down to the second, long free-text notes) compress poorly.
- Wide fact tables. A sales table with 80 columns when the reports need 12.
- DAX calculated columns and calculated tables. These compress worse than columns built in Power Query and make refresh slower.
- Auto date/time turned on. Power BI quietly builds a hidden date table for every date column in the model. With lots of date columns, that adds up.
- Too much history. Ten years of daily transactions when the reports look at the last two.
How to fix it, in the order we'd try
Start with the free fixes. Many models can shrink a lot without changing a single report.
1. Find out what's taking up the space
Before you delete anything, see where the memory is going. The free tool DAX Studio has a VertiPaq Analyzer view that lists every table and column with its size. Often, two or three columns make up most of the model.
2. Remove columns and rows you don't need
In Power Query, remove every column that isn't used in a visual, a relationship, a measure, or a filter. It's easier to add a column back later than to find out six months from now which ones nobody used.
Then filter rows. If the reports only cover the last three years, don't load ten. Microsoft's own guidance recommends filtering history with a Power Query parameter so you can change the window later without rewriting queries.
3. Tame high-cardinality columns
- Split a date-and-time column into a date column and a time column, or drop the time if nobody needs it.
- Round timestamps and decimals to the precision the reports actually use.
- Convert text codes to numbers where you can. Microsoft's example is an order number like "SO123456": strip the "SO" and store it as a number, and it compresses far better.
- Move long text fields (comments, descriptions) out of the model unless someone really reports on them.
4. Move calculated columns into Power Query
If a column can be built in Power Query instead of DAX, build it there. Microsoft's guidance is clear that Power Query columns compress better and refresh faster than DAX calculated columns. Keep DAX calculated columns for the cases that truly need DAX.
5. Turn off auto date/time
In Power BI Desktop, go to File, then Options and settings, then Options. On the Current File page, clear Auto date/time in the Time intelligence section. Do the same on the Global page so new files start without it. Use one proper date table instead. Note that turning it off will break any visuals that relied on the automatic date hierarchy, so check your date visuals afterwards.
6. Stop loading helper queries
If you have Power Query queries that only exist to feed other queries, right-click each one and clear Enable load. They'll still run, but they won't be stored in the model.
7. Use incremental refresh
If the model is big because it has a lot of history, incremental refresh lets Power BI refresh only recent data (say, the last 30 days) and keep older data as it is. That cuts the memory a refresh needs. It works on Pro as well as Premium, but your data source has to support query folding for it to work well.
8. Then consider a bigger license
If the model is lean and still doesn't fit, it's time to look at capacity:
- Premium Per User (PPU) raises the model size limit well beyond Pro's 1 GB and supports the large semantic model storage format.
- Fabric capacity lets you scale memory by moving up a SKU.
On PPU or a capacity, turn on the large format for the model in the Power BI service: open the semantic model's Settings, expand Large semantic model storage format, switch it On, and select Apply.
A bigger license treats the symptom. If you skip steps 1 to 6, you'll pay more every month for a model that's still slower than it needs to be.
If the error happens when a visual loads
Sometimes refresh works fine and the error appears when someone opens a report page. That's a query memory problem: one visual is asking for too much at once. The usual cause is a table or matrix visual showing every row of a large table with no filter. Add a Top N filter or a slicer that limits what it shows, and look for measures that loop over entire tables. Our post on why Power BI reports load slowly covers how to find the visual that's causing it.
When to call someone
You can do most of this yourself with an afternoon and DAX Studio. It's worth getting help if:
- The model is already lean and you're trying to decide between PPU and a Fabric capacity.
- The data source doesn't fold queries, so incremental refresh isn't working.
- Refresh fails with memory errors only some of the time, which usually means something else on the capacity is competing for memory.
- A report that people depend on every morning is broken right now.
If it's one broken refresh, that's exactly what our $299 Power BI fix is for: a senior consultant finds the cause and fixes it, and if we can't fix it, you don't pay. If the model needs a proper rebuild, see our Power BI advisory page.
Sources: Microsoft Learn, Troubleshoot refresh scenarios, Data reduction techniques for Import modeling, Large semantic models.