Tableau Caching: How It Works and How to Optimise It

Tableau uses multiple caching layers to reduce database query load and improve dashboard load times. When a cached query result is available, Tableau serves it without hitting the database — sub-second dashboard loads even for queries that would otherwise take 10–30 seconds. Understanding how caching works and how to configure it is one of the highest-ROI performance optimisations available to Tableau Server administrators.

The three Tableau caching layers

**Session cache (browser cache)**: Each user's browser caches rendered view images and query results within a session. When a user refreshes a page they already visited in the same session, Tableau serves the cached rendering. This cache is per-user, per-session, and clears when the browser session ends or the user explicitly refreshes with the Shift+Refresh shortcut.

**External query cache (server-side result cache)**: Tableau Server caches the results of database queries at the server level. When a workbook is loaded, the query is executed, and the result is cached. The next user who loads the same workbook with the same filter context receives the cached result rather than a new database query. This cache is shared across users and persists across sessions.

The external query cache is the most significant caching layer for server performance. A Tableau Server with hundreds of users loading the same daily operations dashboard hits the database once per cache period and serves the result to all users. Without this cache, the database would receive hundreds of identical queries.

**Extract cache**: When a workbook uses a Tableau extract (.hyper), the extract itself is the performance cache — it is a pre-materialized, compressed copy of the data stored locally on the Tableau Server. Extract queries hit the Hyper database (a local high-performance columnar store) rather than the source database. Extract caching is implicit — any workbook using a published extract benefits from it automatically.

Configuring the external query cache

The external query cache behaviour is controlled by the data source's caching policy. In Tableau Server admin settings, you can configure:

**Automatic (default)**: Tableau uses cached results when available and decides when to refresh based on query frequency and server load. Appropriate for most workloads.

**Always ask for fresh data**: Disables caching for the data source. Every view load triggers a database query. Use only for data sources with strict freshness requirements where stale data has operational consequences.

**Cache as long as possible (maximum)**: Cached results are retained until the server's cache is full and old entries are evicted. Maximises cache hit rate at the cost of potentially serving stale data. Appropriate for data that refreshes infrequently (daily or slower).

**Refresh frequency**: For extract data sources, the cache is invalidated on extract refresh. For live connections, the cache can be configured to refresh on a time schedule (every 30 minutes, every 2 hours, etc.).

Warming the cache

The highest-impact administrative technique for Tableau Server performance is cache warming — pre-loading the cache before users arrive. If the cache is cold when the first users load a dashboard in the morning, they experience the full database query latency. If the cache is warm, all users get immediate responses.

**REST API cache warming**: Use the Tableau REST API to load views via the Tableau API before business hours. A script that authenticates to Tableau Server and makes GET requests to the Views endpoint for your highest-traffic workbooks triggers the queries and caches the results. Run this script 30–60 minutes before your peak usage period.

**Subscription-based warming**: Configure server-side subscriptions for high-traffic workbooks, scheduled to run shortly before business hours. The subscription renders the view (for the image/PDF delivery) and in doing so caches the query results for the subscription user's filter context.

**Tabcmd init**: The tabcmd command-line tool's get command can retrieve view content and in doing so warm the cache. Script tabcmd calls for your key workbooks as part of your morning pipeline.

Extract optimisation for caching

Extract caching effectiveness depends on extract design. The Hyper engine is extremely fast — well-designed extracts serve almost any query in under a second. Poorly designed extracts (too large, unfiltered, with unnecessary columns) are slower.

Extract best practices that improve cache effectiveness:

- Filter extracts to only the rows needed — exclude historical data that is never queried, exclude test records, exclude data outside the users' access scope

- Hide unused fields — the Hyper engine optimises storage for non-hidden fields; hidden fields are not included in the columnar index

- Aggregate data before extract if the workbook only queries aggregated data — an extract of daily summaries is much smaller than an extract of individual transactions

- Use incremental refresh for large extracts — only new rows are added on each refresh, keeping the extract current without full rebuild time

Cache invalidation

The external query cache is invalidated:

- When the underlying data source refreshes (for published extract data sources)

- When the cache timeout expires (for live connections with a configured refresh interval)

- When a Tableau Server administrator manually clears the cache (via the Tableau Services Manager or REST API)

- When the workbook is republished (the cache for that workbook is cleared on publish)

Understanding cache invalidation prevents a common troubleshooting error: users see stale data and assume a pipeline failure, when the actual cause is that the cache has not yet been invalidated after the upstream data refresh. Coordinate extract refresh schedules with business usage patterns — extracts should complete before the peak usage window, not during it.

Monitoring cache performance

Tableau Server logs cache hit rates. The VizQL server logs record whether each query was served from cache or hit the database. The Tableau Repository (a PostgreSQL database) stores query execution data that can be visualised in the built-in admin views under "Stats for Load Times."

The key metric: cache hit rate. A Tableau Server with 80%+ cache hit rate on its busiest workbooks is performing well. A cache hit rate below 50% suggests either the workbooks have very high filter diversity (many unique filter combinations each requiring a separate cache entry) or the cache size is too small for the workload.

For the broader performance context, see tableau server performance tuning guide and tableau workbook optimization. Our managed BI services and Tableau consulting practices include Tableau Server performance optimisation — book a free audit if your dashboards are loading slowly.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.