The architectural fork between Redis and MongoDB for session and state management looks deceptively simple on paper. Redis is fast; MongoDB is persistent. Pick one and move on. In practice, the choice touches latency budgets, durability guarantees, licensing posture, and where your data actually lives under law — and generic benchmarks rarely capture how those trade-offs compound once you are running stateful workloads across European regions.
Both stores rank in the top six on DB-Engines as of April 2026 (MongoDB at five, Redis at six), which tells you the ecosystem is mature on both sides. That maturity cuts both ways: there is a lot of received wisdom that does not survive contact with a real session-state workload.
What you are actually optimising for
Session state has a specific profile: reads and writes are small, frequent, and latency-sensitive; durability requirements vary by application; and data volume per session is rarely large enough to stress a document model. That profile suits Redis well, but it also exposes Redis’s weakest point.
Redis 7.4 is an in-memory key-value and data-structure store with sub-millisecond latency under normal operating conditions. If a Redis instance that stores data only in RAM is restarted without persistence configured, all session data is gone. For a shopping cart or a soft authentication token, that may be acceptable. For a regulated financial workflow or a healthcare session with in-progress form state, it is not.
MongoDB stores data on disk via the WiredTiger storage engine. Writes are durable by default; you do not need to think separately about whether persistence is on. The trade-off is that disk-backed operations carry higher latency than in-memory ones, and for high-frequency session reads at scale, that gap matters.
Redis persistence: the configuration that changes everything
The durability gap between the two stores is real, but it is configurable on the Redis side. Redis offers three persistence modes: RDB (point-in-time snapshots at specified intervals), AOF (append-only file that logs every write and replays it at startup), and a combined RDB-plus-AOF mode. Persistence can also be disabled entirely for pure caching use cases.
AOF durability is controlled by the appendfsync setting. The default, appendfsync everysec, means you can lose at most one second of writes on a crash. appendfsync always is the safest option, logging every write immediately, but under high write loads, frequent fsync operations degrade throughput noticeably. appendfsync no delegates flushing to the OS and is the fastest but least reliable option.
The right Redis persistence mode is not a Redis question — it is a question about what a lost session costs your application and your users.
For most web session workloads, everysec with replication to a replica set is a reasonable compromise. For anything requiring strict durability, either move to always and accept the throughput cost, or reconsider whether Redis is the right primary session store at all.
When MongoDB makes more sense for session state
MongoDB becomes the stronger choice when session objects are complex: nested structures, variable schemas across user types, or sessions that carry query-able metadata. Its document model handles all of that natively, and you avoid the serialisation overhead of flattening a rich object into a Redis hash or string.
If you are already running MongoDB as your primary data store, there is also an architectural argument for consolidating. WiredTiger’s internal cache can accommodate a working set that fits the session read pattern, and MongoDB Enterprise Advanced offers an in-memory storage engine if you need to close the latency gap further. Adding Redis to an existing MongoDB deployment is not free: it introduces a second operational surface, a second backup and restore discipline, and a second failure mode to instrument.
Many production architectures end up combining both: MongoDB as the system of record, Redis as the performance layer for hot session data and short-lived tokens. That is a legitimate pattern, but it should be a deliberate choice rather than the default because someone added Redis to fix a latency problem without questioning whether the underlying data model was the real issue.
Licensing: the question that changed in 2024
Licensing matters for sovereign infrastructure procurement, and the Redis licensing situation shifted significantly over the past two years.
In March 2024, Redis Ltd. moved from BSD to a dual licence under RSALv2 and SSPLv1 starting with version 7.4. Neither is OSI-approved. In response, the Linux Foundation, AWS, Google, Oracle, Ericsson, and others forked Redis 7.2.4 into Valkey under the BSD 3-Clause licence. Valkey is now the default engine for new AWS ElastiCache and MemoryDB instances, and is available on Google Cloud Memorystore.
In May 2025, Redis 8.0 added AGPLv3 as a third licence option alongside RSALv2 and SSPLv1, returning Redis to OSI-approved open-source status by that definition. AGPLv3 requires source disclosure for network-accessed services, which has implications for organisations running Redis 8 as an internal managed service; the precise operational and legal consequences of that requirement are not fully settled and warrant review with your legal team before committing to Redis 8 on private infrastructure.
MongoDB has used SSPL since 2018, so it is not OSI-approved either. For procurement teams with open-source licence policies, neither store is straightforwardly clean; the question is which licence constraint your organisation can manage.
Sovereignty and where the data actually lives
For teams moving stateful workloads to sovereign infrastructure, the managed-service layer matters as much as the data model. Running either store on infrastructure that is ultimately subject to foreign jurisdiction reintroduces the exposure you were trying to close.
MongoDB Atlas has expanded European region coverage and offers zone-based sharding that routes specific user populations to designated geographic regions without application changes. It also holds ISO 27001, SOC 2, and PCI DSS certifications. However, because MongoDB Inc. is a US company, the US CLOUD Act potentially allows US authorities to compel data disclosure regardless of where an Atlas cluster is physically hosted. This is a contested legal interpretation, not settled law, but it is a documented concern and one that regulated sectors take seriously when evaluating whether Atlas satisfies their data residency requirements.
We run managed Redis and managed MongoDB at DIVERSITY on infrastructure that sits entirely within European jurisdiction. For latency-sensitive session workloads serving Northwestern European users, AMS1 in Amsterdam provides dense peering via AMS-IX and sub-10ms reach across Benelux, the UK, and Western European markets, which matters when session reads are in the critical path of every authenticated request. The legal boundary does not move based on where a hyperscaler’s physical rack happens to sit.
A practical decision framework
Choose managed Redis for session state when: sessions are small and structurally simple, sub-millisecond read latency is a hard requirement, acceptable data loss on failure can be bounded to one second or less, and you have the operational capacity to configure and monitor persistence correctly.
Choose managed MongoDB for session state when: session objects are complex or schema-variable, you are already running MongoDB and want to consolidate operational surface, durability must be guaranteed without additional configuration, or your session data needs to be query-able for audit or analytics purposes.
Choose both deliberately when: you need Redis-speed reads for active sessions and MongoDB-grade durability for session history or downstream processing, and you are prepared to operate two stores with separate backup, monitoring, and failover disciplines.
The benchmark question is worth addressing directly: no independent, current, European multi-region session-state benchmark comparing the two stores exists in the public literature. Vendor-published figures (including Redis Ltd.’s own comparisons against Atlas) use vector-search workloads, not session-state ones, and older third-party benchmarks used software versions from 2017. Test against your own session profile, at your target region, before treating any published number as authoritative for your architecture.
