Why teams put Redis in front of Apache Superset
Dashboards in Apache Superset send queries to your analytics warehouse every time a chart renders, a filter changes or a user reloads a page, and people wait on those results. A caching layer is the component that can reuse query results across users and requests, so that identical work does not have to hit the warehouse again. In Superset's four-component architecture, the caching layer is optional, but the Superset architecture documentation says that alerts and reports, async queries and dashboard thumbnails require it along with the Celery worker and beat components, and most installations use Redis and Celery for these.
That dependency changes the decision. If you plan to run scheduled reports, let SQL Lab queries run asynchronously or show dashboard thumbnails, you are already committing to a cache backend and worker processes, so the question becomes how Redis is hosted, sized and protected rather than whether to add it. If your use is limited to interactive dashboards, the caching layer still shapes how often charts go back to the warehouse, which matters for warehouse cost and for how consistent users see the same numbers. Before you commit, confirm with your own usage which of these features you need in the first release, because each one adds work to the cache and to the workers.
Redis is not the only choice for this role, and the licensing picture has changed. Redis 8.0 and later are offered under a license you choose among RSALv2, SSPLv1 and AGPLv3, according to the Redis licenses page, while Valkey is an open BSD-3-Clause fork maintained under the Linux Foundation. Your legal and procurement teams should review the license terms for the Redis version you pick, and your platform team should confirm that the Redis client library Superset uses works with the server you deploy. The rest of this page assumes Redis, but the same design questions apply to any compatible server.
Cache options and when each fits
This table compares the Superset cache types that Redis can back: data cache, filter state, Explore and metadata caches, plus per-chart timeouts and result size limits. Read each row for when it fits and what it costs in freshness versus warehouse load. The main takeaway is that longer timeouts cut warehouse queries but show older numbers, so set them per dataset according to how fast the underlying data changes.
| Cache option | When to use it | Freshness versus warehouse load | What to confirm |
|---|---|---|---|
| Data cache | Stores chart query results so repeated views of the same chart skip the warehouse | Longer timeouts lower warehouse load but users may see figures that lag the source data | Timeout keys and default behavior in the configuration docs for your Superset version |
| Per-chart and per-dataset timeout | Gives fast-changing datasets short lifetimes and stable reference datasets long ones | Short timeouts keep numbers current at higher query volume; long timeouts reduce queries but risk stale results | Whether your version applies dataset-level and chart-level timeouts in the same order you expect |
| Filter state cache | Keeps selected dashboard filter values so users return to the same view | Improves navigation speed; does not refresh underlying data, so it does not reduce warehouse queries on its own | Expiry behavior and whether it is shared across users or per session |
| Explore cache | Holds chart configuration from Explore so saved or in-progress views reload quickly | Speeds up editing; the data behind a chart still follows the data cache rules | Which key store it uses and how its lifetime is set in your release |
| Metadata cache | Holds schema and table lists fetched from connected databases | Shorter lifetimes show new tables sooner but cause more metadata queries against the warehouse | Refresh behavior for database schema lists and whether it runs on demand or on a schedule |
| Result size limits | Caps rows or bytes returned to the browser and cached, protecting Redis memory and the web tier | Lower limits reduce memory use but can truncate large tables users expect to see in full | The row limit settings and cache size behavior in your version's configuration reference |
| Shared Redis instance | Suits teams that want one cache backend for all cache types with one monitoring target | A single eviction policy applies to every cache type, so one heavy cache can push out others | Eviction policy and memory limits set on the Redis side for your expected load |
Setting cache timeouts and result size limits per chart and dataset
Cache timeouts decide how stale a dashboard may look and how much warehouse load Redis absorbs. Each timeout is a business decision about freshness, sensitivity and cost, so the owner of each dashboard should set it with the data team and security reviewers rather than inherit a global default.
Freshness requirement per dashboard
Ask the dashboard owner how old the numbers may be before someone makes a wrong decision. A finance close dashboard and a support queue view need different timeouts, and Superset applies cache timeouts per chart and per dataset, so one value rarely fits every dashboard. Record the agreed freshness next to each dashboard so later changes have a documented reason. Check that the timeout matches how often the upstream data actually loads.
Row level security and cache keys
Cached results must never cross users. Before setting any timeout on a dataset that uses row level security or per-user filters, confirm with your Superset version that cache keys vary by the security context that affects the query. Test with two users who should see different rows, then wait out the timeout and compare results. If you cannot prove separation, shorten the timeout or disable caching for that dataset.
Auto-refresh and cache interaction
Dashboards with auto-refresh rerun their queries on a schedule, so a short timeout can turn a refresh interval into constant warehouse load. Decide the shortest refresh interval a dashboard may use and make sure the cache timeout is at least long enough to absorb that rerun. Review auto-refresh settings with the dashboard owner when the timeout changes, because the two settings together determine query volume.
Result size limits for Redis memory
Large query results stored in Redis consume memory that other caches and sessions also need. Set a row limit on datasets and charts that return wide or unbounded results, and decide which dashboards are allowed to exceed it. Ask your team which Redis maxmemory setting and eviction policy apply to the cache database, since eviction can remove entries early. Confirm the limit with a test query on the largest expected dataset.
Exports and SQL Lab results
Cached chart data is not the only result that can sit in Redis. Decide whether exports, SQL Lab results and async query output may be cached, for how long, and who may download them. Cached exports widen the data sensitivity question, so set their timeouts with the same review as row level security datasets. Document the decision in the dataset owner's runbook.
Outage behavior and stale data
When Redis is unavailable, Superset falls back to querying the warehouse, which can produce a sudden load spike on the same dashboards. Decide in advance whether that fallback is acceptable for each tier of dashboard, and whether a Sentinel setup with at least three Sentinel instances is needed to keep the cache available. Test a Redis failure during a busy period and watch warehouse query volume before you rely on the timeouts you set.
Configuring Superset to use Redis for caching
This sequence takes a Superset installation from a provisioned Redis instance to verified cache hits, with each cache backed by its own key prefix and timeout and the Celery broker confirmed before any user traffic depends on it. It is written for the platform team that will run the deployment and the engineer who will tune it.
Choose the Redis line and license
Decide which Redis build you will run before provisioning anything. Redis 7.2 and earlier are published under BSD-3-Clause, Redis 7.4.x through 7.8.x (then called Redis Community Edition) are under the dual RSALv2 or SSPLv1 license, and Redis 8.0 and later can be used under a license you choose among RSALv2, SSPLv1 and AGPLv3. Have legal confirm which terms fit your use, especially if you modify Redis code. Valkey, a fork under BSD-3-Clause, is a permissively licensed alternative that existing Redis client libraries can connect to without code changes. Done when the chosen product, version and license are written into the deployment record and approved internally.
Provision Redis with Sentinel for high availability
Deploy the Redis server or Valkey service on infrastructure you control, with persistence settings, memory limits and network access restricted to the Superset web and worker hosts. If you need automatic failover without Redis Cluster, plan Sentinel with at least three Sentinel instances, as the Redis Sentinel documentation recommends for a robust deployment. Confirm the Redis version and that the server runs on a supported operating system. Done when a client on a Superset host can run a PING against the master and, if Sentinel is used, the Sentinel instances report the expected master.
Set the cache backend and key prefixes
In superset_config.py, point the data, metadata, filter state and Explore caches at Redis using the CACHE_CONFIG, DATA_CACHE_CONFIG, FILTER_STATE_CACHE_CONFIG and EXPLORE_FORM_DATA_CACHE_CONFIG keys, and give each cache its own CACHE_KEY_PREFIX so entries never collide and can be flushed separately. Store the Redis password in a secret manager or environment variable, not in the file itself. Confirm the exact configuration keys against the Superset configuration documentation for your version before you copy them. Done when Superset starts without errors and the Redis key listing shows a distinct prefix for each cache after a page load.
Set timeouts per cache
Set a default CACHE_DEFAULT_TIMEOUT for each cache, then add per-chart and per-dataset overrides where data freshness differs. Short timeouts suit fast-changing operational data, while slowly changing reference data can hold longer. Record each choice next to the dataset owner so that stale-data complaints can be traced to a setting. Also review result size limits and row limits for the data cache, because large cached payloads consume Redis memory quickly. Done when each dataset or chart with a non-default timeout appears in the change record with its owner and a reason, and a test refresh confirms the expected expiry in Redis.
Verify cache hits with a test chart
Create a test chart on a dataset with a known query, open it twice, and watch the Superset logs and Redis keys. The first load should write a cache entry under the data cache prefix and the second should be served from it without a new warehouse query. Check the query history in your warehouse to confirm the second load issued no query. Repeat for a dashboard with native filters to confirm filter state is cached under its own prefix. Done when the warehouse query count is unchanged on the second load and the expected keys exist under each prefix.
Confirm the Celery broker configuration
Alerts, reports, async queries and thumbnails depend on the caching layer and Celery workers, and most installations run Redis or a compatible service as the Celery broker. If you use the same Redis for the broker, assign it a separate database number or instance from the cache so that a cache flush cannot remove queued tasks. Confirm the CELERY_CONFIG broker and result backend settings, then submit a test async query and check that a worker picks it up. Done when a worker logs the completed task and the broker keys are unaffected by a cache flush in staging.
Test the failure path before go-live
Stop the Redis master in a staging environment and observe what Superset does. Record whether pages load with cache misses, whether Sentinel promotes a replica, how long the Superset hosts take to reconnect, and whether users see errors on Explore, filters or async queries. Confirm with your Superset version's behavior before relying on any fallback, and document the result as the runbook for an outage. Done when the test outcome, failover time and user-visible symptoms are written into the operations runbook and reviewed by the platform owner.
Choosing between Redis Open Source 8, Redis 7.2 and Valkey
The license under which you run your cache decides which Redis line you can deploy without a legal question, and that choice should be made before the first Superset cache configuration is written. Redis 8.0 and later are offered under a license of the user's choice among RSALv2, SSPLv1 and AGPLv3, effective from the Redis 8 general availability release. Redis 7.4.x through 7.8.x (then called Redis Community Edition) sit under the dual RSALv2 or SSPLv1 license, which is not OSI-approved. Redis 7.2.x and earlier remain under BSD-3-Clause. Because Superset's data, metadata, filter state and Explore caches all write through the same Redis connection, a licensing mismatch affects every cache type at once, not just one.
Get a legal review before you pick a Redis line, especially if your organization offers Superset to outside users, embeds dashboards in a product, or modifies Redis artifacts. The Redis licenses FAQ says teams on Redis 7.2 or earlier with unmodified artifacts see no impact, while teams that offer modified Redis code as a network service must make the modified source available to that service's users. Ask counsel to confirm how the license terms apply to your deployment model, and record the decision with the exact version you chose. Valkey is a BSD-3-Clause fork of open-source Redis, made just before Redis moved to source-available licenses. It is an open community project under LF Projects, LLC, with the Linux Foundation holding the Valkey trademarks. Existing Redis client libraries connect to Valkey without code changes, which makes it a practical option for Superset. However, the Valkey migration guide covers moving from Redis OSS 7.2 and earlier, and it warns that Redis Community Edition 7.4 and later write data files that Valkey cannot read. If your current cache runs on 7.4 or later, plan a different migration method and confirm it with the Valkey project and your own test environment before cutover.
Redis Sentinel for high availability and what failover means for Superset
Sentinel can keep a Redis cache available when a primary node fails, but Superset treats the cache as disposable, so failover shows up as cache misses and dropped writes rather than as lost data. The cards below cover what Sentinel does, how to size it, how clients must connect, and what to test before you rely on it.
Automatic replica promotion
Sentinel monitors the Redis primary and promotes a replica to master when the primary stops responding. Superset does not need to be told which node is current, but it does need a Sentinel-aware client to find the new primary. Ask your team to confirm how long the failover takes in your environment by measuring it under load, since the timing depends on your Sentinel settings and network, not on a value this page can promise.
Three Sentinel instances
The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances. Sentinels vote on whether a primary is down and on which replica to promote, so two instances cannot form a reliable majority. Place the three Sentinels on separate hosts or failure domains so that losing one machine does not also remove the quorum that decides failover.
Sentinel-aware client configuration
Superset reaches Redis through a client library configured for its cache and Celery broker settings. Confirm that the client is configured with the Sentinel addresses and service name rather than a fixed host, so that after failover it asks Sentinel for the current primary. A client pointed at a fixed IP keeps writing to a demoted node and fails in ways that look like a Superset bug.
Failover can drop cache writes
Redis replication is asynchronous, so writes accepted by the old primary just before it failed may not reach the promoted replica. For Superset this usually means a few cache entries are missing and the next request recomputes them against the warehouse. Treat this as expected behavior, but check that chart and filter results are correct after a failover, and that a burst of recomputation does not overload your warehouse.
Valkey Sentinel uses the same model
Valkey Sentinel provides the same high availability model for Valkey when Valkey Cluster is not used, and it also recommends at least three Sentinel instances. If you chose Valkey as the cache backend, the client configuration and failover tests in this section carry over with product-specific names and settings. Confirm the exact Sentinel configuration keys for your chosen version in the Valkey documentation before you deploy.
Test Superset against failover
Before production, run a planned failover while users load dashboards, and check that Superset reconnects without restarting its web and worker processes. Observe Celery tasks for alerts, reports and thumbnails, because tasks in flight during the switch may fail and need a retry policy. Record the observed behavior and share it with the team that owns the warehouse, so the cache-miss pattern is understood before an unplanned outage occurs.
What happens to Superset when Redis goes down
Do Superset dashboards fall back to the warehouse when Redis is unavailable?
Usually yes, but the exact fallback behavior must be verified for your Superset version and Redis setup. When the cache backend cannot be reached, Superset generally treats the request as a cache miss and runs the chart query against the database again. That keeps dashboards working, but every chart that would have been served from cache now sends its SQL to the warehouse. Confirm this by reading the cache configuration and error handling for your release, then test it with a dashboard you know well. Watch the query count on the warehouse side during the test, since that is the cost you will actually feel.
Will a Redis outage stop async queries and scheduled reports?
It can, because the Celery broker and result backend often run on the same Redis or a sibling instance. The architecture documentation says alerts and reports, async queries and dashboard thumbnails depend on the caching layer and worker components, and most installations use Redis and Celery for them. If the broker is down, new tasks cannot be queued, so SQL Lab async runs and scheduled reports may fail or be delayed. Check whether your deployment uses one Redis for both roles. If it does, a single outage affects both, and you should decide in advance how failed reports are retried and who is alerted.
Why do dashboards get slow after a cache outage?
Pages slow down because cache misses send every chart query to the warehouse at once, and warehouses have their own concurrency and queue limits. Dashboards with many charts, native filters or tabs issue more queries per load, so the effect is larger on busy pages. Users may also see charts load in sequence rather than together. Reduce the impact by reviewing which dashboards have the most charts, checking the chart timeout settings, and confirming that the web tier has enough worker capacity to hold connections open while queries wait. Sizing these layers is a separate task from the cache itself.
Can Redis Sentinel keep the cache available during a failure?
Sentinel provides high availability for Redis when you are not using Redis Cluster. It monitors the master and promotes a replica automatically if the master fails. The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances, so plan for three separate hosts or failure domains. Sentinel does not remove the need for application behavior testing. Superset must be configured to connect through Sentinel, and the failover window may still produce a short run of errors that Superset handles as cache misses or failed tasks. Test the failover itself, not only the configuration file.
Does Superset store user data or permissions in Redis, so an outage could lock users out?
Redis is used for caching and for task brokering in the usual setup, and the metadata database holds users, roles and dashboard definitions. Losing Redis should not remove accounts or permissions, but login sessions, filter state or cached results that depend on the cache backend may behave differently during an outage. Confirm which of the Superset cache keys use Redis in your configuration, and whether session storage is also placed there. Your test plan should include logging in, opening a dashboard with native filters, and running SQL Lab during the outage.
How do we test a Redis outage in staging before production?
Run a planned failure with a copy of production-like data and the same Superset version, Redis topology and worker layout. Record a baseline first: page load times, warehouse query counts, async query completion and report delivery. Then stop the Redis primary or block its network path, and repeat the same steps while watching Superset and worker logs. Include a Sentinel failover case if you use it, and a full loss case where no Redis is reachable. Restore service and compare results with the baseline. Repeat the test after every Superset upgrade, since the UPDATING.md notes and the upgrade guide may change cache behavior.
Should we use Valkey or Redis for the Superset cache and broker?
Superset does not depend on one vendor, so the choice comes down to licensing, support and your own policy. Redis 8.0 and later can be used under RSALv2, SSPLv1 or AGPLv3 at your choice, while Valkey is licensed under BSD-3-Clause and is backed by the Linux Foundation. Redis 7.4 through 7.8 use dual RSALv2 or SSPLv1 licenses, which are not OSI-approved. Legal review is the right step before you pick a version. Whichever server you run, confirm that your Superset version and Python Redis client work with it, and test failover with that exact server.
Securing the cache layer and keeping cached results private
Superset's cache holds query results, which can contain the same rows a user would see through the dashboard itself. The cards below cover the controls that keep that cache private: how clients authenticate and connect, where Redis sits on the network, how cache keys separate users and roles, how the secret key is handled, and what gets logged.
Require Redis authentication and TLS
Every Superset web and worker process connects to Redis as a client, so an unauthenticated or plaintext Redis instance exposes cached query results to anyone who can reach the port. Configure a Redis user with access limited to the keys and commands Superset needs, and enable TLS for connections that cross a network boundary. Confirm the connection settings your Redis version and Superset cache configuration accept before rollout, and test that a client without credentials is refused.
Place Redis on a private network segment
Redis should accept connections only from the Superset web tier, Celery workers and, where used, Sentinel nodes. Keep it on an internal subnet with no route from user networks or the public internet, and restrict access with security groups or firewall rules. Sentinel monitoring traffic and replication traffic should also stay on that segment. Review the network policy whenever you add a worker pool or move Superset to a new cluster.
Isolate cache keys by role and data access
Superset caches chart results keyed on the query and its inputs. Where row level security or role-based data access applies, two users can send identical SQL but be entitled to different rows, so a shared key can leak data across them. Review how your Superset version builds cache keys for RLS-filtered queries, and verify with two test accounts that differently scoped users never receive each other's cached results. Set a per-tenant key prefix if you run multiple Superset instances on one Redis.
Manage SECRET_KEY for signed values
Superset requires a user-specified SECRET_KEY to start, and it signs session data and other values the application issues. Store it in a secrets manager, not in a checked-in config file, and keep the same value across web and worker containers so signatures verify everywhere. Rotate it with PREVIOUS_SECRET_KEY so existing sessions are not all invalidated at once. Confirm which cache-related values depend on this key in your version before changing it.
Log access and cache changes
Record Redis authentication failures, configuration changes, and failover events in your central logging system, and retain them according to your policy. On the Superset side, keep query and export logs that show which user triggered each cached result. Logs help you investigate a suspected cross-user exposure and show whether cache flushes or Sentinel failovers coincided with incidents. Confirm the log fields your Redis and Superset versions emit before you build alerts on them.
Questions teams ask before they set up Redis caching
What drives the cost of setting up Redis caching for Superset?
The main cost driver is how many layers you cache and how many environments you must validate them in. Caching work covers the data cache, metadata cache, filter state and Explore cache, plus Redis topology choices such as a single instance or Redis Sentinel with at least three Sentinel instances. Costs rise with the number of dashboards and datasets that need per-chart timeout decisions, with the amount of load testing against your warehouse, and with the number of networks and secrets involved. Ask any partner for a quote that lists each cache, the topology, the environments, and the testing included, and separate one-time build work from ongoing support.
How long does Redis caching setup take for Superset?
Duration depends on scope rather than on a fixed rule. A single Redis instance serving one Superset environment is a much smaller job than a Sentinel-based highly available setup with separate caches, staged rollouts and verification against real dashboards. Timing is also shaped by access requests, change windows and how many dashboards need per-chart timeout reviews. Confirm the timeline in the written scope before work starts, and ask for the milestones, the environments covered and the acceptance tests that close each one.
What does our team need to provide before caching work starts?
Plan to provide access to the Superset environments and the metadata database, the warehouse or analytics databases Superset queries with a service account suited to caching tests, and the identity setup that controls who sees which dashboards. You will also need a Redis hosting location inside your infrastructure, network rules between Superset, Celery workers and Redis, a secrets store for Redis passwords, and named owners for each environment. Ask for a written access list so the work does not stall on missing permissions.
Can our internal team set up Redis caching without a partner?
Yes, if your team has Superset administration skills, Redis operations experience and someone who understands your warehouse query costs. The Superset configuration documentation covers the cache settings, and the Redis and Valkey documentation covers Sentinel behavior. The risks are in the gaps: choosing timeouts without knowing which charts are shared, configuring Sentinel without tested failover, and missing the link between cache keys and row level security. Decide which of these your team can cover, and bring in a partner for the parts it cannot test confidently.
What recurs after launch, such as upgrades and license checks?
Several items recur. Superset upgrades require backing up the metadata database, running superset db upgrade and superset init, testing in staging, and checking UPDATING.md for breaking changes, so cache settings must be retested each time. Redis and Valkey publish frequent security releases, so patching is ongoing. Licensing also needs periodic review: Redis 8.0 and later are offered under a choice of RSALv2, SSPLv1 or AGPLv3, and Redis 7.4 to 7.8 use a dual RSALv2 or SSPLv1 license. Valkey is BSD-3-Clause. Have legal confirm which license fits your use before you pick a Redis version.
How does caching affect our warehouse cost?
Caching reduces repeated queries to your warehouse when many users open the same charts within the cache timeout. The saving depends on how often identical queries repeat, so it is largest for shared dashboards and smallest for ad hoc exploration where every query differs. Long cache timeouts reduce warehouse spend but can show stale numbers, so the timeout should follow how often each dataset refreshes. Measure cache hit rates and warehouse query counts before and after launch, and set per-dataset timeouts from that data rather than from a single global default.
What happens to users if Redis goes down?
Superset keeps working when the cache is unavailable, but queries go back to the warehouse, which raises load and can slow dashboards, and features that depend on Celery and the caching layer, such as alerts, reports and async queries, may fail. Redis Sentinel can promote a replica to master automatically when it is configured with at least three Sentinel instances, but failover still needs testing in your network. Ask for a documented failure runbook that covers alerts for Redis health, warehouse load during an outage and the steps to restore service.
How DeployOpen scopes and delivers Redis caching for Superset
DeployOpen starts every Redis caching engagement with a written scope before any configuration changes. The scope names the Superset version and deployment method, the Redis or Valkey topology (standalone or Sentinel), the cache families in use (data, metadata, filter state and Explore caches), the per-chart and per-dataset timeouts, the result size limits, and whether Celery workers depend on the same Redis instance for async queries, alerts, reports and thumbnails. It also records what the client already runs, including the metadata database, the identity provider and the warehouse connections that the cache will sit in front of. The written scope is where the client decides which Redis distribution to use, since the Redis licensing has changed across major releases and the choice should be confirmed against the client's own legal review. Ask for the scope, deliverables and acceptance checks in writing before work starts.
Configuration is delivered inside the client's own infrastructure, whether that is their cloud accounts, data centers or restricted networks. DeployOpen works through the client's change process, keeps cache settings in version-controlled configuration where the client's deployment method allows it, and documents each cache key prefix, timeout and Sentinel setting so the client's own engineers can operate the result. Before handover, the failover and outage behavior is tested in a staging environment that mirrors production. Tests cover a primary failover under load, a Sentinel quorum loss, a full Redis outage and the recovery of Celery workers and async jobs, and the results are recorded against the expected behavior of Superset when the cache is unavailable. Confirm with DeployOpen which of these tests run in production and which need a maintenance window.
After handover, ongoing support, Superset and Redis upgrades and periodic failover testing can be covered by a retainer. Retainers suit teams that expect Superset releases, Redis or Valkey security releases and changes to dashboard traffic to keep arriving, because each of these can change cache behavior. The retainer scope should be agreed in writing, with the upgrade approach, the test environments used and the response expectations spelled out, and any service levels should be stated in the contract rather than assumed. Ask for a quote based on the written scope, and ask which parts of the work would recur and which would be one-time.
