Report loading speed is one of the most visible and most user-impactful aspects of Power BI deployment quality. An executive opening a board dashboard at 8am on a Monday should see their report render in under two seconds not wait through a 12-second cold-query execution against the semantic model while 30 other users are doing the same thing simultaneously. Power BI query caching on Premium and Embedded capacity is the feature that makes this possible for frequently accessed reports, by serving pre-computed results to the report consumer rather than executing a fresh DAX query on every page open. Understanding how it works, what its constraints are, and when to enable it is a fundamental capacity administration skill.

What Power BI Query Caching Actually Does

Query caching stores the results of DAX queries that were executed during a report page load. When a subsequent user opens the same report page under sufficiently similar conditions — same dataset, same security context, same page — Power BI serves the stored result directly rather than re-executing the underlying DAX queries against the semantic model. The report page renders from the cached results, bypassing the Analysis Services engine entirely for that load event.

The performance benefit is most pronounced in two scenarios: reports with computationally expensive DAX measures that take several seconds to execute, and reports accessed by many concurrent users where un-cached execution would generate a burst of simultaneous queries against the semantic model at peak usage times. In both cases, query caching reduces the interactive query load on the capacity and delivers faster, more consistent render times to end users.

"Query caching is the difference between a report that renders from memory and one that re-computes from scratch every time someone opens it. For high-traffic executive dashboards, enabling it correctly is one of the simplest capacity performance improvements available."

How the Cache Is Built and When It Is Used

The cache is populated the first time a user opens the report after the cache is empty — specifically when the report landing page loads and its visual queries execute. Power BI captures the query results from that initial load and stores them associated with the dataset context and the user's security identity.

An important operational detail: query caching currently applies only to the report landing page. Once a user interacts with the report applying a slicer, drilling down, navigating to a different page those interaction-driven queries are not cached. The user's interactive session executes live against the semantic model from that point forward. This means query caching primarily benefits the initial report open experience, which is also where the performance difference between a cached and uncached load is most visible to end users.

Cache Scope: User and Dataset Context

Cached results are user-specific and dataset-specific. The cache for a given report page is not shared across users each user has their own cached result. This is a direct consequence of how Row-Level Security interacts with caching, which is covered in the next section. The cache is also dataset-specific: if the same report is connected to a different dataset, the cache is independent for each dataset context.

The Three Dataset-Level Caching Settings Explained

Query caching behaviour is controlled at the dataset level via the dataset's Settings page in the Power BI Service. Navigate to the dataset's settings accessible from the workspace view via the dataset's context menu and locate the Query Caching section. Three options are available.

Capacity Default. This setting applies whatever the capacity administrator has configured as the default for the capacity. In most Power BI Premium capacities, the capacity-level default is query caching Off — meaning datasets set to "Capacity Default" will not cache queries unless the capacity administrator has explicitly changed the default. This is the setting for most datasets that have never been explicitly configured.

Off. Query caching is disabled for this specific dataset, regardless of the capacity default. Every report page open against this dataset executes fresh DAX queries. Use this setting for datasets where data freshness is critical and even a briefly stale cache result would be unacceptable live operational dashboards, trading systems, or any dataset with very frequent refresh cycles.

On. Query caching is explicitly enabled for this dataset. The first report page open populates the cache, and subsequent opens within the cache validity window serve from the stored results. Use this setting for datasets where report load speed is a priority and the data does not change between refresh cycles — executive dashboards, management packs, weekly or daily reporting datasets.

Query Caching and Row-Level Security

Row-Level Security (RLS) and query caching interact in a way that is critical to understand before enabling caching on any dataset where RLS is active. Because RLS filters what data each user can see, two users opening the same report page will receive different query results each filtered to their own permitted data scope. Power BI's query caching handles this correctly: cached results are always user-specific and security-scoped.

The practical implication is that query caching does not compromise data security a cached result for User A is never served to User B. However, it also means that the cache population overhead scales with the number of distinct users who open the report, rather than being shared across all users. For a report accessed by 500 users with individual RLS profiles, the cache must be populated once per user, which reduces but does not eliminate the capacity load from concurrent morning access.

For datasets without RLS where all users see the same data query caching can be more effective because the cached result is shared across users with the same dataset context, and the cache hit rate is higher relative to the number of page loads.

How Dataset Refresh Affects the Cache

The query cache is automatically invalidated when the dataset refreshes. After a scheduled or manual refresh completes, the existing cached results are discarded and the cache is rebuilt on the next report page open. This means that for datasets with very frequent refresh schedules hourly or more frequently the cache provides limited benefit because it is invalidated before most users benefit from it.

For datasets with daily or less-frequent refresh schedules, the cache can persist for the full duration between refreshes, providing consistent performance benefits to all users who access the report during that window. A daily-refresh management report that is accessed by 50 executives every morning is an excellent candidate for query caching: the data is stable for 24 hours, the cache is rebuilt once per day after the overnight refresh, and all subsequent morning opens serve from the cache.

Capacity-Level Implications and the Capacity Default Setting

Query caching is a Premium and Embedded capacity feature. It is not available for datasets hosted on shared capacity Pro workspaces. The capacity administrator controls the default caching behaviour for all datasets on the capacity through the capacity management settings in the Admin Portal. Setting the capacity default to On means all datasets configured as "Capacity Default" will cache queries automatically, which may be appropriate for production reporting capacities but less appropriate for development or test capacities where data changes frequently.

From a capacity resource perspective, the query cache consumes storage on the capacity to hold result sets. For large datasets with many distinct users and RLS profiles, the aggregate cache storage can be meaningful. Capacity administrators managing the CPU and memory profile of a Power BI Premium capacity should account for cache storage when assessing overall capacity utilisation, particularly on capacities with many large datasets.

When to Enable Query Caching — and When to Leave It Off

The decision to enable Power BI query caching on Premium for a given dataset is straightforward when the dataset's usage pattern is understood. Enable caching for datasets that are accessed frequently by multiple users, have a stable data refresh cycle of daily or less frequent, serve a report landing page with computationally expensive visuals, and where the initial load experience is a pain point for end users.

Leave caching Off or explicitly set it to Off — for datasets that refresh very frequently (hourly or more), serve operational dashboards where even minutes-old cached data would create confusion, contain live data streams, or are used primarily in development and testing contexts where result accuracy on every open matters more than load speed.

A governance-level best practice is to review the caching setting as part of the dataset deployment checklist for every dataset promoted to production on a Premium capacity. Defaulting to Off in development and explicitly enabling On for production datasets that meet the caching criteria is a clean, auditable pattern that prevents accidental stale data serving in development environments while ensuring that production report performance is optimised.

Caching Settings Decision Guide

Next Steps for Power BI Performance Governance

Power BI query caching on Premium is one component of a broader capacity performance governance programme. Combined with staggered refresh scheduling, incremental refresh, aggregation tables, and Apply All Slicers query reduction, it contributes to a layered approach to capacity utilisation management that keeps interactive report performance consistent even as the estate grows and concurrent user counts increase.

For organisations managing multiple datasets across a Premium or Fabric capacity, establishing a standard dataset deployment checklist that includes an explicit caching configuration decision — based on the dataset's refresh frequency and access pattern — is a simple governance improvement that pays dividends in consistent user experience and reduced capacity monitoring burden. If your organisation needs help designing or auditing its Power BI capacity governance framework, speak with a certified Power BI consultant at Numlytics.

For a broader view of capacity performance management, our posts on managing CPU spikes on Power BI Premium capacity and limiting capacity utilisation in Microsoft Fabric cover the complementary controls that work alongside query caching to keep enterprise Power BI estates performing reliably.