Apache Superset Cache Strategies for Performance 2026

Cache is Apache Superset's number one performance lever. Properly configured, it transforms a 10s dashboard into 100ms. Misconfigured, your users see stale data or the database is saturated. This guide details cache strategies in 2026.

1. Three Superset cache levels

Level	What	Typical TTL
Data cache	Query results (chart data)	5 min - 24h
Metadata cache	Dashboard list, permissions, datasets	1h
Thumbnail cache	PNG previews of dashboards	1h - 1 day

If you want a pre-cached instance, TVL Managed Superset applies optimal cache strategies by default.

2. Multi-role Redis configuration

import redis

REDIS_URL = "redis://redis:6379"

DATA_CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 60 * 60 * 24,
    "CACHE_KEY_PREFIX": "data_",
    "CACHE_REDIS_URL": f"{REDIS_URL}/1",
}

CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 60 * 60,
    "CACHE_KEY_PREFIX": "meta_",
    "CACHE_REDIS_URL": f"{REDIS_URL}/2",
}

THUMBNAIL_CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 60 * 60 * 24 * 7,
    "CACHE_KEY_PREFIX": "thumb_",
    "CACHE_REDIS_URL": f"{REDIS_URL}/3",
}

3. TTL adapted per use case

Use case	Recommended TTL
Daily exec dashboard	24h
Real-time ops dashboard	1-5 min
Ad-hoc SQL Lab	5-15 min
Multi-tenant embedded	15 min
Public dashboard	1-24h (depending on freshness)

4. Override per dataset

Override TTL at dataset level (Edit dataset → Performance → Cache timeout):

• fct_orders: 5 min (real-time data);
• dim_customers: 1 day (few changes);
• fct_daily_summary: 24h (nightly dbt refresh).

5. Programmatic invalidation

After a dbt run, invalidate the cache:

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

This way the cache stays consistent with the actual data freshness.

This configuration is applied by default on TVL Managed Superset, which follows community best practices.

6. Cache warming

For critical dashboards, pre-warm the cache after ETL:

# Nightly post-dbt job
curl -X POST https://superset.example.com/api/v1/dashboard/42/warm_up_cache

In the morning, users see dashboards instantly.

7. Cache monitoring

• Hit ratio (target >90%): redis-cli INFO stats | grep keyspace_hits;
• Memory usage: if close to maxmemory, increase;
• Evictions: high = cache too small;
• p99 latency: must stay under 10 ms.

8. Redis sizing

Load	Redis RAM
50 users	1 GB
500 users	4 GB
SaaS 100 embedded tenants	16 GB cluster

9. Common pitfalls

• maxmemory-policy noeviction by default → Redis refuses writes;
• TTL too short on exec dashboard → DB saturated in the morning;
• TTL too long on ops dashboard → stale data;
• No invalidation post-ETL → inconsistency;
• Shared cache between tenants without prefix → possible leak.

10. Conclusion

A well-thought-out Apache Superset cache strategy combines TTLs adapted per usage, post-ETL invalidation, hit ratio monitoring. With these basics, your dashboards are 10 to 100 times faster, at modest Redis cost (a few €/month).

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).

For more: Redis cache, Postgres tuning, slow Superset?.