Memory issue

Hi PBI_2K26,

On the limit: the capacity setting Query Memory Limit (%) (Admin portal > Capacity settings > your capacity > Power BI workloads) can only lower the memory one query may use, not raise it above what the SKU allows. On F64 that ceiling is 10 GB, so the only way past it is a larger SKU.

Why a plain table hits it: with only columns, the visual still groups by every column combination across the 600M rows and sorts the result to find the first rows to show. Every extra high-cardinality column (IDs, timestamps, free text) multiplies that work. The few hundred rows you see are cheap. The full grouping behind them is what uses the memory.

Ways to keep one visual:

1. Don't let it run unfiltered. Add a visual-level filter or a slicer (date range, region) that is always set, so the grouping only covers a slice.
2. Drop or move the widest columns. Remove IDs and long text from the table and show them on a drillthrough page for one row.
3. Sort by a column people actually need. Sorting by a unique ID or a timestamp forces a sort over everything.
4. For real row-level lists at this size, use a paginated report on the same model, or a DirectQuery detail table to Snowflake in a composite model. Both are made for long lists. An Import table visual isn't.

Hello PBI_2K26​ 

Even though the visual contains only imported columns and no DAX calculations, Power BI still needs memory to execute the query, build intermediate result sets, perform sorting, grouping, and render the visual. With a source table of approximately 600 million rows, a simple table visual can still generate a very memory-intensive query.

For an F64 capacity, the per-query memory limit is governed by the capacity's resource governance settings. While capacity administrators can configure the Query Memory Limit (%) setting, the maximum memory available to a single query is ultimately constrained by the SKU and available capacity resources. Simply increasing the setting may not always resolve the issue if the query is already approaching the SKU's practical limits.

To remain under the limit while keeping a single visual, consider:

• Reducing the number of columns displayed in the table.
• Applying filters or slicers to reduce the number of rows returned.
• Using aggregations instead of detailed transactional data where possible.
• Implementing incremental aggregation tables or aggregation-aware models.
• Reviewing column cardinality, as high-cardinality columns significantly increase memory requirements.

In short, the issue might not be caused by DAX but by the amount of data that the visual is trying to materialize. The query is exceeding the current memory allocation, and model optimization or query reduction is typically the recommended approach rather than relying solely on increasing the memory limit.