Redis Cache for Apache Superset: 2026 Guide

Redis is the most rentable component you can add to Apache Superset: it accelerates dashboards by a factor of 10 to 100 on repeated queries, serves as a Celery broker for async tasks, and stores multi-replica sessions. This guide explains how to configure each role in 2026.

1. Redis's 4 roles in Superset

1. Query result cache (DATA_CACHE_CONFIG): avoids re-querying the database on every chart render;
2. Metadata cache (CACHE_CONFIG): speeds up the list of dashboards, datasets, slices;
3. Celery broker: queue of async tasks (alerts, reports, heavy exports);
4. Session store: essential in multi-replica.

If you want to skip this configuration, TVL Managed Superset integrates a Redis pre-configured for the 4 roles from instance creation.

2. Sizing

Profile	Redis RAM	Persistence
Dev / POC	256 MB	Optional
Production 50 users	1 GB	RDB every 10 min
Production 500 users	4 GB	AOF + RDB
Multi-tenant SaaS	8 GB+ cluster	AOF + cluster mode

3. superset_config.py configuration

import redis

REDIS_HOST = os.environ.get("REDIS_HOST", "redis")
REDIS_PORT = int(os.environ.get("REDIS_PORT", 6379))

# 1. Query result cache (chart data)
DATA_CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 60 * 60 * 24,  # 24h
    "CACHE_KEY_PREFIX": "superset_data_",
    "CACHE_REDIS_URL": f"redis://{REDIS_HOST}:{REDIS_PORT}/1",
}

# 2. Metadata cache
CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 60 * 60,
    "CACHE_KEY_PREFIX": "superset_meta_",
    "CACHE_REDIS_URL": f"redis://{REDIS_HOST}:{REDIS_PORT}/2",
}

# 3. Celery broker
class CeleryConfig:
    broker_url = f"redis://{REDIS_HOST}:{REDIS_PORT}/0"
    imports = ("superset.sql_lab", "superset.tasks")
    result_backend = f"redis://{REDIS_HOST}:{REDIS_PORT}/0"
    worker_prefetch_multiplier = 1
    task_acks_late = True
CELERY_CONFIG = CeleryConfig

# 4. Sessions
SESSION_TYPE = "redis"
SESSION_REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT, db=3)
SESSION_PERMANENT = False
SESSION_USE_SIGNER = True

Note the use of different Redis databases (db=0, 1, 2, 3) to isolate roles.

4. Timeout strategy

Cache type	Recommended timeout	Justification
Executive dashboards (D-1)	24h	Daily data, low invalidation
Operational dashboards	5-15 min	Freshness/load tradeoff
Ad-hoc charts / SQL Lab	5 min	Exploration, low reuse
Metadata (roles, permissions)	1h	Stable, reload on invalidation

You can override per dataset in Superset (Edit dataset → Performance → Cache timeout). This configuration is applied by default on TVL Managed Superset, which follows community best practices.

5. Cache invalidation

Three mechanisms:

• Time-based: automatic expiration (TTL);
• Manual: "Force refresh" button in chart;
• Programmatic: API call POST /api/v1/cache/invalidate after ETL.

To sync cache and dbt freshness, trigger invalidation at the end of the dbt run:

curl -X POST https://superset.example.com/api/v1/cache/invalidate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"datasource_uids": [""]}'

6. Redis high availability

• Redis Sentinel: 3 sentinels + 1 primary + 1-2 replicas, automatic failover. Sufficient for most;
• Redis Cluster: 16384-slot sharding, horizontal scale. For very high load;
• Managed: ElastiCache, OVHcloud Valkey, Azure Cache, Upstash.

7. Persistence

Redis would lose sessions and cache on restart without persistence. Three modes:

• RDB: periodic snapshots. Light but possible loss between snapshots;
• AOF: append-only file. Almost no loss but more resource-intensive;
• RDB + AOF: both. Recommended in serious production.

8. Security

• Private network: Redis must never be exposed to Internet;
• Auth: requirepass or Redis 6+ ACL;
• TLS: Redis 6+ supports native TLS, enable for inter-zone connections;
• Disable dangerous commands: FLUSHDB, FLUSHALL, CONFIG in production.

9. Monitoring

Key metrics to track:

• Hit ratio (target >90%);
• Memory used / max memory;
• Evictions (cache too small);
• Connections;
• Latency p99.

Tools: redis-cli INFO, redis_exporter + Prometheus + Grafana, RedisInsight for inspection.

10. Common pitfalls

• maxmemory-policy at noeviction by default → Redis refuses writes when full. Use allkeys-lru or volatile-lru;
• Too generic cache: a single Redis for cache + sessions + broker. If Redis saturates, everything goes down together. Prefer 2 distinct Redises at high volume;
• Non-persistent session: all users disconnected on reboot;
• Cluster vs standalone confused: Python libs don't have the same API.

11. Conclusion

Redis is the #1 performance lever for Apache Superset. Properly configured, it transforms a slow instance into a responsive platform with dashboards loading in less than a second. Misconfigured, it's the opposite. The 9 rules above cover 95% of cases.

Want the benefits of Apache Superset without the friction of installation and maintenance? Deploy your instance in 3 clicks with TVL Managed Superset, hosted in Europe (OVHcloud, Roubaix, France), pre-configured Redis included.

For more: Celery async workers, caching strategies, Postgres tuning.