MongoDB and Redis are the two tools you run into most often when working with NoSQL. Both sit under the NoSQL umbrella, yet the roles they take in production differ. MongoDB is a document store that holds durable data as the primary store, while Redis is an in-memory store that typically takes a supporting role — cache, sessions, and the like.
When I built chat-services, I first stored messages in Redis, then moved to MongoDB once durability became a requirement. The retrospective only touched on this briefly. This post walks through why two tools sitting under the same NoSQL umbrella end up in different roles, across data model, storage, schema, scaling, and use cases.
Data Model
Where the two tools first differ is the unit of storage.
Redis is a key-value store. Each key maps to a single value, and value types include data structures like String, List, Set, Sorted Set, Hash, and Stream. Single-key reads and writes are the most natural access pattern; complex queries rely on the client side or external indexes.
MongoDB is a document store. Instead of plain key-value, it stores JSON-like documents (BSON) as units. A single document can hold nested fields, arrays, and varied types, all grouped into collections. A document often corresponds to a single entity, which maps naturally onto domain models.
Storage and Durability
Redis keeps data in memory. Durability is optional, with two mechanisms available: RDB snapshots and AOF (Append Only File) command logs. In a typical configuration with only RDB enabled, changes after the last snapshot can be lost during a failure. AOF narrows the loss window by logging each write, but memory remains the primary storage medium.
MongoDB stores data on disk. The storage engine is WiredTiger by default, and writes are persisted to disk along with the journal. Durability is built in from the start. Adding a replica set replicates data across nodes, so data survives a single-node failure.
Schema and Query
Redis queries are commands. Commands like GET, SET, HGETALL, ZRANGE are called directly per data structure. Conditional searches are hard to express with the base commands, so modules like RediSearch are added on top for richer queries. There is no schema concept, and how a value is interpreted is up to the application.
MongoDB provides its own query language, MQL. find, aggregate, and update express conditional searches, aggregation, and partial updates. Collections do not enforce a schema, but JSON Schema validation can constrain field shapes when needed. This fits early stages where domains shift often, and validation can be layered in incrementally once things stabilize.
Scaling and Availability
Redis Cluster splits the key space into a fixed number of slots and distributes them across nodes. Each slot is assigned to a node, and one node owns the keys for its slots. Replication uses a master-replica structure. When a failure happens, Sentinel or Cluster promotes a replica to master.
MongoDB scales in two ways: sharded clusters and replica sets. A sharded cluster splits a collection by shard key across multiple shards. A replica set keeps copies of data on multiple nodes; if the primary fails, one of the secondaries is automatically elected as the new primary. Automatic failover is part of the default behavior.
Use Cases
Here is where their roles diverge.
Redis often sits in supporting roles: cache, session storage, rate limiting, distributed locks, short-lived queues. It fits cases where fast response and low latency matter, and where data can live in memory and tolerate eviction.
MongoDB takes the primary store role. Durable domain data lives there, and it tends to be chosen when schemas shift or when document shapes map naturally onto the domain. Users, content, orders, and logs are typical examples.
Both tools fall under NoSQL, but in practice the question that splits them is whether the data needs to be durably stored or kept as a supporting cache.
Used Together
In practice, the two are used together more often than alone.
The most common setup puts MongoDB as the primary store and Redis in front as a cache layer. Frequently read data sits in the Redis cache to reduce disk access; on a cache miss, MongoDB is read and the result fills the cache again. Supporting data like sessions, rate limits, and one-time tokens lives only in Redis, leaving MongoDB to focus on domain data.
In chat-services, messages started in Redis and moved to MongoDB once durability was needed. Adding a Redis cache layer in front of MongoDB later would put the same two tools in the roles that suit them best.
Choosing Between Them
The comparison, in table form:
| Aspect | Redis | MongoDB |
|---|---|---|
| Data model | Key-value | Document |
| Primary medium | Memory | Disk |
| Default durability | Optional (RDB/AOF) | On by default (journal + replica set) |
| Query | Commands | MQL (find/aggregate) |
| Schema | None | Flexible + optional validation |
| Scaling | Cluster (slot distribution) | Sharded cluster (shard key) |
| Auto failover | Sentinel/Cluster | Replica set by default |
| Primary role | Cache, sessions, rate limit | Primary store |
Three things decide it:
- If durable storage is required, MongoDB is the primary and Redis sits as a supporting cache.
- If latency matters most on a hot path, Redis.
- If schemas shift often, MongoDB’s document model fits the domain well.
Even under the same NoSQL umbrella, the two tools take on different roles. That’s why the combination shows up so often in real systems.
References
- chat-services — Redis → MongoDB transition context
- What RDB Transaction ACID Actually Guarantees — RDB transaction guarantees
- MongoDB docs — Storage Engines, Replica Set, Sharded Cluster
- Redis docs — Persistence, Cluster, Replication