Redis vs MongoDB: In-Memory Data Store or Document Database?

Redis vs MongoDB comes up because both are "NoSQL" and both can store JSON. In practice they do different jobs. Redis is an in-memory data structure server: the dataset lives in RAM and every command is an atomic operation on a structure. MongoDB is a disk-based document database: the dataset lives on disk, a cache holds the working set, and a query engine and indexes let you ask flexible questions of it.

Use MongoDB as the database of record for application data shaped like documents. Use Redis for caching, sessions, counters, rate limits, leaderboards, queues, and other hot state that must be fast and can be rebuilt or tolerate a small loss window. Many applications use both, with Redis caching reads that would otherwise hit MongoDB.

Redis 8 narrows the gap on paper. It ships JSON documents and the Redis Query Engine in the default build, so you can store and query documents in Redis. That does not change the core trade-off: everything still has to fit in memory, and durability is something you configure rather than something you get by default.

Redis vs MongoDB: memory first or disk first

The difference that drives every other section is where the data lives.

Redis holds the dataset in memory. Reads and writes never wait on disk, and persistence happens in the background through RDB snapshots or an append-only file (AOF). The cost is that your data can be no larger than the RAM you pay for, and anything written since the last persist point can be lost in a crash.

MongoDB writes to disk through the WiredTiger storage engine. WiredTiger keeps a write-ahead journal and takes checkpoints every 60 seconds, and its internal cache defaults to the larger of 50% of (RAM minus 1 GB) or 0.256 GB. Frequently used documents and indexes stay in that cache, so a well-sized MongoDB deployment serves much of its traffic from memory too. When the working set outgrows the cache, MongoDB slows down; Redis runs out of room.

Durability, tested

I ran the official images: Redis 8.10.2 and MongoDB 8.3.11. Each test writes a record, kills the container with SIGKILL, restarts it, and reads the record back.

Redis with its default configuration:

$ redis-cli CONFIG GET appendonly
appendonly
no
$ redis-cli CONFIG GET save
save
3600 1 300 100 60 10000
$ redis-cli SET order:1001 paid
OK
$ docker kill -s KILL redis && docker start redis
$ redis-cli GET order:1001

The key is gone. The default saves a snapshot after 3,600 seconds with at least one change, 300 seconds with 100 changes, or 60 seconds with 10,000 changes, and a single write had not triggered one.

Redis started with --appendonly yes:

$ redis-cli SET order:1002 paid
OK
$ docker kill -s KILL redis && docker start redis
$ redis-cli GET order:1002
paid

With AOF enabled, the key survives. The default appendfsync everysec policy fsyncs once per second, so a crash can still cost up to about a second of writes.

MongoDB, with a journaled write:

db.orders.insertOne({ _id: 1004, status: "paid" }, { writeConcern: { w: 1, j: true } })
// { acknowledged: true, insertedId: 1004 }

After the kill and restart, db.orders.findOne({ _id: 1004 }) returned { _id: 1004, status: 'paid' }.

On a replica set, MongoDB's default write concern has been majority since 5.0, so an acknowledged write is on most members. Redis replication is asynchronous, and the Redis Cluster documentation says Redis Cluster does not guarantee strong consistency and can lose acknowledged writes. For data you cannot recreate, MongoDB's defaults are the safer starting point.

Data modelling

A MongoDB document holds a record and its nested parts together:

db.orders.insertMany([
  { _id: 1, customer: { name: "Ada", country: "UK" },
    items: [{ sku: "kb-01", qty: 1, price: 89 }, { sku: "ms-02", qty: 2, price: 25 }],
    status: "paid" },
  { _id: 2, customer: { name: "Bob", country: "US" },
    items: [{ sku: "kb-01", qty: 1, price: 89 }],
    status: "pending" },
  { _id: 3, customer: { name: "Cy", country: "UK" },
    items: [{ sku: "mn-27", qty: 1, price: 310 }],
    status: "paid" }
])

You can query any field, including nested ones, and add indexes as queries appear. Schema validation is optional, so different documents in a collection can carry different fields.

Redis models data as keys holding structures. A user is often a hash, a session a string with a TTL, and a ranking a sorted set:

$ redis-cli HSET user:42 name Ada plan pro
(integer) 2
$ redis-cli ZADD leaderboard 3200 ada 2950 bob 4100 cy
(integer) 3
$ redis-cli ZREVRANGE leaderboard 0 1 WITHSCORES
1) "cy"
2) "4100"
3) "ada"
4) "3200"

The key name is your primary access path, and naming conventions such as user:42 or order:1001 do the work that collections and _id do in MongoDB. Without the Query Engine, there is no way to ask "which users are on the pro plan?" other than maintaining a set of those user IDs yourself.

Querying: aggregation pipeline vs Query Engine

MongoDB's query language handles filters, projections, sorts, and multi-stage aggregations. Against the three orders above:

db.orders.find(
  { "customer.country": "UK", status: "paid" },
  { _id: 1, "customer.name": 1 }
)
// [ { _id: 1, customer: { name: 'Ada' } }, { _id: 3, customer: { name: 'Cy' } } ]

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $unwind: "$items" },
  { $group: { _id: "$customer.country",
              revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } } } },
  { $sort: { revenue: -1 } }
])
// [ { _id: 'UK', revenue: 449 } ]

With a compound index on {"customer.country": 1, status: 1}, explain() on the find showed an IXSCAN in the winning plan. $lookup provides joins between collections when you need them. For tuning, see how to fix slow MongoDB queries.

Redis 8 includes JSON and the Query Engine by default. MODULE LIST on the 8.10.2 image showed ReJSON, search, timeseries, bf, and vectorset. The same data and questions look like this:

JSON.SET order:1 $ '{"customer":{"name":"Ada","country":"UK"},"status":"paid","total":139}'
JSON.SET order:2 $ '{"customer":{"name":"Bob","country":"US"},"status":"pending","total":89}'
JSON.SET order:3 $ '{"customer":{"name":"Cy","country":"UK"},"status":"paid","total":310}'

FT.CREATE idx:orders ON JSON PREFIX 1 order: SCHEMA
  $.customer.country AS country TAG
  $.status AS status TAG
  $.total AS total NUMERIC

FT.SEARCH idx:orders "@country:{UK} @status:{paid}" RETURN 1 total
FT.AGGREGATE idx:orders "@status:{paid}" GROUPBY 1 @country REDUCE SUM 1 @total AS revenue

FT.SEARCH returned order:1 (total 139) and order:3 (total 310), and FT.AGGREGATE returned country UK, revenue 449. It works, and it is fast, but the schema is declared up front, fields must be indexed before you can query them, and the index adds to the memory you are already paying for. MongoDB lets you query an unindexed field with a collection scan and add the index later.

DB Pro

Work With Your Databases Like A Pro

Query, explore, and manage your databases with a beautiful desktop app and built-in AI.

Download Now

Transactions and atomic updates

Both systems make single-record updates atomic. MongoDB updates a document with operators such as $set, $inc, and $push in one atomic write. Redis commands like INCR, HINCRBY, LPUSH, and ZINCRBY are atomic because Redis executes commands one at a time.

They differ across multiple records. MongoDB supports multi-document ACID transactions on replica sets and sharded clusters, with a default lifetime limit of 60 seconds (transactionLifetimeLimitSeconds). Redis MULTI/EXEC runs a batch without interleaving other clients, but it does not roll back when a command fails at runtime:

SET stock:sku1 10
SET name:sku1 widget
MULTI
DECR stock:sku1
INCR name:sku1
EXEC
1) (integer) 9
2) (error) ERR value is not an integer or out of range
GET stock:sku1
"9"

The decrement stays applied. In Redis, conditional multi-key logic belongs in a Lua script or function, with WATCH for optimistic checks.

Expiry and caching behaviour

Redis was built for data with a lifespan. SET session:a1 ... EX 3600 stores a value that expires in an hour, and an expired key reads as missing immediately. When memory fills, an eviction policy such as allkeys-lru removes old keys. The default is noeviction, and with a 2 MB maxmemory limit a new write failed with:

(error) OOM command not allowed when used memory > 'maxmemory'.

MongoDB has TTL indexes, created with expireAfterSeconds. The TTL background task runs every 60 seconds, and MongoDB's documentation notes that expired documents can remain for longer on a busy server. That suits log retention and old sessions, not precise timeouts. MongoDB never evicts data to make room; it stores what you write until you delete it.

Scaling

Redis scales vertically first, since one process serves commands on a single main thread for data access. Redis Cluster shards keys across primaries using 16,384 hash slots. Multi-key commands work only when all keys map to the same slot, which you arrange with hash tags such as user:{123}:profile and user:{123}:account.

MongoDB scales reads and availability with replica sets, which elect a new primary on failure. It scales writes and storage with sharding on a shard key you choose. Picking that key well is the hardest part of running a large MongoDB deployment, and the equivalent in Redis is keeping related keys in the same hash slot.

Licensing

Both projects left permissive or OSI licences at some point, so check the terms before you ship either.

MongoDB moved from AGPLv3 to the Server Side Public License (SSPL) for all Community Server releases on or after October 16, 2018. SSPL is not OSI-approved. The source is available, and self-hosting for your own application is allowed, but offering MongoDB as a service triggers SSPL's source disclosure requirements. MongoDB Atlas is the vendor's managed service. Self-managed Search and Vector Search, which run in a separate mongot process, reached general availability for Community Edition and Enterprise Advanced on June 30, 2026.

Redis 7.2 and earlier are BSD 3-Clause. Redis 7.4, released after the March 2024 licence change, moved to a dual RSALv2 and SSPLv1 licence, which led to the Valkey fork under the Linux Foundation. With Redis 8 in 2025, Redis added AGPLv3 as a third option, so Redis 8 and later can be used under an OSI-approved licence again. Versions 7.4 to 7.8 remain RSALv2/SSPLv1. The Redis licensing page has the details, and our Redis alternatives guide covers Valkey and other forks.

When to choose MongoDB

• The data is your system of record.
• Records are naturally documents with nested fields and arrays.
• You need ad hoc queries, secondary indexes, and aggregations on fields you did not plan for.
• The dataset is larger than you want to pay to hold in RAM.
• You need multi-document transactions with rollback.

When to choose Redis

• You need a cache in front of MongoDB, PostgreSQL, or an API.
• Data expires on a schedule: sessions, tokens, rate limit windows.
• Operations are structural: increment, rank, push, pop, intersect.
• You need pub/sub or lightweight queues. See our Redis Streams guide and Redis vs Kafka.
• The hot dataset fits in memory with room for growth.

Using Redis and MongoDB together

The common pattern is cache-aside. The application reads from Redis, falls back to MongoDB on a miss, and writes the result to Redis with a TTL. Writes go to MongoDB first, then delete or update the cached key. Session data and rate limits live only in Redis, and orders, users, and content live in MongoDB.

That split plays to each system's defaults: MongoDB's journal and replica set protect the records, and Redis serves the hot path from memory.

Verdict

MongoDB is the better choice for storing application data. Redis is the better choice for making access to that data faster and for state that lives in memory by design. Redis 8's JSON and Query Engine make it capable of document queries, but only for datasets you are willing to hold in RAM, with durability you configure yourself.

If you are weighing MongoDB against other document stores, see DynamoDB vs MongoDB, Couchbase vs MongoDB, or MongoDB alternatives. If the other option on your list is DynamoDB, read DynamoDB vs Redis. DB Pro connects to both, as a MongoDB desktop client and a Redis desktop client.