Server-side sessions and session lifetime in Apache Superset

The right backend usually follows from what your team already runs. Superset's architecture has four parts: the Flask and React application, a metadata database, an optional caching layer and optional Celery workers. If your deployment already has the caching layer for async queries, alerts, reports or thumbnails, Redis is already in the stack and adding session storage to it adds no new service. If the team wants fewer moving parts, the metadata database can hold sessions without another component. Both options add load to a service you must size and monitor, so the choice should be made against your existing service inventory rather than a general preference.

• Redis when the cache already runs: Session reads happen on every authenticated request, so the Redis instance needs capacity and monitoring that match its current duties.
• Database when the stack should stay small: Sessions share the metadata database's backups, access controls and upgrade windows, and their write load adds to that database.
• Ownership of the service: Confirm which team gets paged if the session store fails and whether that team already runs the chosen service.
• Supported interfaces: Confirm the session interface names and related settings for your Superset version in the configuration documentation before writing configuration.
• Environment parity: Use the same backend in staging and production so that logout and expiry tests reflect production behavior.

Check which services already run in production and who operates each one before you pick a backend.

The session store is in the login path, so its outage affects users immediately. With a Redis backend, an unreachable Redis instance typically means that requests cannot read their session, so users are logged out or see errors until the store returns. With a database backend, the same effect follows from an unreachable metadata database, which also stops dashboards, chart queries and metadata access. Because the metadata database is needed for nearly everything Superset does, its outage is usually already a major incident, and a session store on the same database adds little new failure surface. Redis outages are narrower, but they can still lock out users while leaving the rest of the application partly working. Test the exact behavior in your version, including whether users receive an error page or a login redirect.

• Redis outage: Expect session loss and forced re-login if the store is down or flushed, and confirm whether Redis persistence is enabled.
• Database outage: Expect the whole application to stop, which makes session storage a minor addition to the existing dependency.
• Failover path: Document the Redis replica or sentinel arrangement, or the database high availability setup, and test failover with live sessions.
• Timeouts: Set client timeouts so a slow store does not hang every request for an extended period.
• Communication: Prepare a user message for forced re-login after a session store incident.

Run a planned failover of the chosen store while logged in, then confirm which sessions survive.

Session records are short-lived, so their backup needs differ from application data. Backing up session data is seldom useful, because restoring an old session can revive access that users have since ended. The database backend is covered by the metadata backup you already take, which includes session rows unless you exclude them, so retention depends on how often expired sessions are removed. A Redis backend may hold sessions only in memory, which means a restart clears them, or it may persist them to disk, which requires a decision about snapshot and append-only file settings. Either way, the expiry behavior determines how long stale records remain.

• Restore policy: Decide whether a restore should revive sessions. In most cases, restored sessions should be invalidated so users sign in again.
• Database cleanup: Confirm how expired session rows are removed and schedule the cleanup if the backend does not do it automatically.
• Redis persistence: Decide whether sessions survive a restart, and document the choice for the audit file.
• Key-value encryption: Confirm how session contents are protected at rest in each store and what your data classification requires.
• Log records: Check whether session identifiers appear in logs and whether that is acceptable.

Ask the platform owner to show the expiry cleanup and the restore procedure for session data before go-live.

When Superset runs as several web instances behind a load balancer, every instance must read the same session store, or a user will be logged out when a request lands on a different node. A shared Redis or database backend provides that shared view. Logout also needs to reach all instances: a session deleted in the store stops working everywhere at once, which is the behavior cookie sessions cannot give you. Without a shared store, each instance keeps its own state and logout becomes unreliable. Check that the load balancer does not depend on sticky sessions to hide these gaps, since stickiness can mask a misconfiguration until an instance restarts.

• Shared store: Point every web instance, including any Celery workers that read sessions, at the same backend and key prefix.
• Logout propagation: Test that a logout on one instance ends the session on every other instance within your accepted window.
• Sticky sessions: Do not rely on them for correctness. Test with stickiness disabled.
• Secret key consistency: All instances need the same SECRET_KEY configuration so that session cookies they issue are accepted by the others.
• Rolling restarts: Verify that users keep their sessions while instances are replaced one at a time.

Run a logout test from a browser that is routed to instance A, then confirm the session is rejected on instance B.