Should I move session storage from DB to an in-memory store for performance?

[MiaCT]

I'm trying to decide if we should move our main application's stateful session storage from our managed database service to a dedicated in-memory store for better performance. I'm just not sure if the complexity of managing another service and handling failover is worth the latency gain we'd see from a purpose-built system.

[Aaron.J]

We moved session state to Redis last year. Lookups were faster on the hot path, but the gains weren't magical. We still paid for network hops and occasional misses. The failover and monitoring overhead was real, so we kept a DB fallback for persistence and used a light heartbeat to keep caches healthy.

[JosephNJ]

I'd be wary of adding another service just for sessions. If the app already scales, a cache can become a single point of failure. We did a small pilot and the ops burden and testing costs ate into the ROI. Maybe start with a tiny experiment and a feature flag rather than a full fork.

[James92]

Do we actually know the bottleneck is the session lookup, or are we chasing a latency vibe while the real issue is DB contention or CPU pressure on app servers?

[ScottPL]

One thing we did: keep per instance caches but skip a central store. It cut churn during peaks and avoided a big architectural shift. In a real outage, though, you notice what you forgot to plan for and wish you'd tested failover earlier.