Redis vs MongoDB: Cache, Store or Both? (2026)

Quick verdict

Short answer

Choose MongoDB as the primary database when you need to store documents durably, query them in many ways, and keep data that is larger than memory. Choose Redis when you need very low-latency access to data that fits in RAM: caches, sessions, rate limiters, leaderboards, queues and pub/sub. In many applications the answer is both: MongoDB holds the records and Redis caches hot reads or handles ephemeral state. Redis 8 can store and index JSON, but its own documentation describes persistence trade-offs that make it a different kind of primary store from MongoDB.

How we know: This comparison is research-based: licences, persistence, transactions, clustering, data types and query features were checked against the official Redis documentation and legal pages, the Valkey and Linux Foundation pages, and the MongoDB documentation in October 2026; prices were taken from the Redis and MongoDB pricing pages. We have not run performance tests, so no speed claims are made.

Redis keeps its dataset in memory and exposes data structures through commands rather than a query language: strings, hashes, lists, sets, sorted sets, streams, bitmaps, geospatial indexes and more. Since Redis 8.0 (May 2025), the release notes state that Redis Search, JSON, time series and five probabilistic structures (Bloom filter, Cuckoo filter, Count-min sketch, Top-k and t-digest) are part of Redis Open Source itself rather than separate Redis Stack modules, with vector sets added as a preview. Persistence to disk is optional, through RDB snapshots and an append-only file (AOF). The current release in the Redis documentation is 8.10. Redis Ltd. also sells Redis Cloud and Redis Software.

MongoDB is a document database. Data is stored as BSON documents in collections, written to disk through the WiredTiger storage engine, and queried with the MongoDB Query API (find(), aggregation pipelines). It has secondary indexes of many kinds, multi-document ACID transactions, replica sets for high availability and native sharding. The current release in the MongoDB manual is 9.0, and MongoDB, Inc. runs the MongoDB Atlas cloud service on AWS, Azure and Google Cloud.

These two are not like-for-like rivals in the way MongoDB vs PostgreSQL is. Redis's own eviction documentation opens by saying that Redis is commonly used as a cache in front of a slower database, which is exactly the role it often plays next to MongoDB. This page explains where each fits, where they overlap (Redis 8 JSON and search) and when it makes sense to run both.

Side by side

Aspect	Redis	MongoDB
Primary role	In-memory data structure store: cache, sessions, queues, counters, pub/sub, real-time features	Durable general-purpose document database (system of record)
Where data lives	In RAM; optional RDB snapshots and AOF log on disk	On disk (WiredTiger) with an in-memory cache; datasets can exceed RAM
Data model	Keys holding strings, hashes, lists, sets, sorted sets, streams; JSON, time series and vector sets in Redis 8	BSON documents in collections, up to 16 MiB per document
Querying	Commands per data type; Redis Search (`FT.SEARCH`, `FT.AGGREGATE`) for secondary indexing of hashes and JSON	MongoDB Query API with rich filters, aggregation pipelines and `$lookup` joins
Transactions	`MULTI`/`EXEC` run commands as one isolated unit, with `WATCH` for optimistic locking; no rollback	Multi-document ACID transactions with commit and abort
Durability default	RDB snapshots by default; AOF with `appendfsync everysec` can lose about one second of writes	Default write concern `w: "majority"` with on-disk journaling on most replica sets
Scale-out	Redis Cluster: 16,384 hash slots, asynchronous replication, no strong consistency guarantee	Native sharding with shard keys, mongos routers and config servers
Licence (self-managed)	Redis 8+: choice of RSALv2, SSPLv1 or AGPLv3	Community Server: SSPL v1.0
Vendor cloud	Redis Cloud (Free, Essentials, Pro) on AWS, Google Cloud and Azure	MongoDB Atlas (Free, Flex, Dedicated) on AWS, Azure and Google Cloud
Main trade-off	Very low-latency structures, but memory-bound and with weaker durability and transaction semantics	Durable, queryable records at scale, but not designed as an in-memory cache or message broker

Key differences

Complements more often than substitutes

The most common pattern is cache-aside: the application reads from Redis first, falls back to MongoDB on a miss, and writes the result into Redis with an expiry. Redis's eviction documentation describes this use directly: cache entries are copies of persistently stored data, so it is usually safe to evict them when memory runs out. MongoDB remains the source of truth.

// Redis (redis-cli): cache a product for 10 minutes
SET product:1001 "{\"name\":\"Desk\",\"price\":120}" EX 600
GET product:1001

// MongoDB (mongosh): the system of record
db.products.findOne({ _id: 1001 }, { name: 1, price: 1 })

Other jobs Redis does well alongside a document database are session storage, rate limiting, distributed locks, leaderboards with sorted sets, and lightweight queues with lists or streams. None of these require MongoDB to be replaced; they take short-lived, high-churn data off it.

Memory and persistence

Redis serves its dataset from RAM, so the size of the data you can hold is bounded by memory (Redis Cloud adds auto-tiering to SSD on its Pro plan). The maxmemory directive caps usage, and the eviction policy decides what happens at the limit: the default noeviction returns errors on writes, while policies such as allkeys-lru or allkeys-lfu drop keys, which is what you want for a cache and what you do not want for a primary store.

The persistence documentation lists four options: RDB point-in-time snapshots, the AOF log, no persistence, or both. It warns that with RDB alone "you should be prepared to lose the latest minutes of data" after an unclean stop, and that AOF with the default appendfsync everysec policy can lose about one second of writes; appendfsync always is safer but described as very slow. Redis suggests using both methods "if you want a degree of data safety comparable to what PostgreSQL can provide". Redis 8.10 adds a BACKUP command family for online backups.

MongoDB writes to disk through its storage engine, keeps a working set in memory, and the manual states that the implicit default write concern is w: "majority", which waits for on-disk journaling on a majority of replica set members (with an exception for some arbiter configurations, where it falls back to w: 1).

JSON and search: where Redis 8 overlaps with MongoDB

Redis 8 includes a JSON data type and Redis Search, so you can store JSON documents, index fields and query them. That makes Redis a plausible document store for data that fits in memory and needs very fast reads, for example a product catalogue served at the edge of an application, or vector search for AI features.

// Redis 8 (redis-cli): JSON document with a search index
JSON.SET product:1001 $ '{"name":"Desk","price":120,"category":"office"}'
FT.CREATE idx:product ON JSON PREFIX 1 product: SCHEMA
  $.name AS name TEXT $.price AS price NUMERIC $.category AS category TAG
FT.SEARCH idx:product "@category:{office} @price:[100 200]"

// MongoDB (mongosh): the same query on a collection
db.products.createIndex({ category: 1, price: 1 })
db.products.find({ category: "office", price: { $gte: 100, $lte: 200 } })

The difference is in what surrounds the query. MongoDB adds aggregation pipelines, $lookup joins, schema validation, multi-document transactions with rollback, and storage that is not bounded by RAM. Redis Search queries are fast but scoped to indexed keys, and Redis transactions do not roll back.

Transactions and consistency

A Redis transaction queues commands between MULTI and EXEC and runs them as one isolated step, so no other client is served in the middle. The documentation is explicit that "Redis does not support rollbacks of transactions": if one command fails at runtime, the others still run. WATCH provides optimistic check-and-set, and Lua scripts and functions are also atomic. In Redis Cluster, multi-key operations only work when all keys share a hash slot, which you arrange with hash tags such as {user:1000}.

The Redis Cluster documentation also states that Redis Cluster "does not guarantee strong consistency" and can lose acknowledged writes during failover, because replication is asynchronous. MongoDB offers multi-document ACID transactions on replica sets and sharded clusters, with commit and abort, and tunable read and write concerns. If your writes must not be lost or partially applied, that difference matters more than raw speed.

Licensing history and the Valkey fork

Redis has changed licence twice. Per Redis's licence page, versions up to 7.2 were BSD-3-Clause; Redis 7.4 to 7.8 were offered under a choice of RSALv2 or SSPLv1 (the March 2024 change, neither of which is OSI-approved); and Redis 8.0 and later are offered under a choice of RSALv2, SSPLv1 or AGPLv3. Redis states that adding AGPLv3 means Redis Open Source is again available under an OSI-approved licence.

In response to the 2024 change, the Linux Foundation launched Valkey in March 2024. According to the Linux Foundation announcement, Valkey continues development from Redis 7.2.4 under the BSD 3-clause licence; valkey.io lists 9.1.2 (1 September 2026) as its latest release. Valkey is a separate project, so features added to Redis after the fork (including the Redis 8 JSON and search integration) should not be assumed to exist in Valkey.

MongoDB Community Server has been under the SSPL v1.0 since October 2018. Neither product's self-managed server is under a permissive licence today, so if licence terms matter to you, read the actual texts; we describe terms only and do not give legal advice.

Pricing and licensing

Self-managed. Redis Open Source and MongoDB Community Server are free to download and run under the licences above. Redis Software (self-managed enterprise) and MongoDB Enterprise Advanced are sold through sales.

Redis Cloud. Listed on the Redis pricing page in October 2026, in USD: Free, 30 MB on shared infrastructure; Essentials from 0.007 USD per hour (5 USD per month minimum), 250 MB to 100 GB, single database; Pro from 0.014 USD per hour with a 200 USD per month minimum, dedicated deployment, multi-region active-active and auto-tiering. All three are offered on AWS, Google Cloud and Azure.

MongoDB Atlas. Listed on the MongoDB pricing page in October 2026, in USD: Free tier with 512 MB of storage; Flex at 0.011 USD per hour, capped at 30 USD per month; Dedicated clusters from 0.08 USD per hour (M10). Atlas is billed hourly with monthly invoices.

Because Redis holds data in RAM and MongoDB on disk, the same gigabyte of data usually costs more to keep in Redis. Compare plans by the memory you need for Redis and by storage and compute for MongoDB, not by headline hourly price.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Redis strengths

Data is served from memory with purpose-built structures: sorted sets, lists, streams, hashes, bitmaps, geospatial and probabilistic types
Key expiry and eviction policies make it a natural cache and session store
Redis 8 bundles JSON, Redis Search, time series and vector sets in Redis Open Source
Pub/sub and streams cover messaging and lightweight queue patterns
Redis 8 is available under AGPLv3 as well as RSALv2 and SSPLv1, and Valkey offers a BSD-licensed fork

MongoDB strengths

Durable by default: majority write concern with journaling on typical replica sets
Rich querying with aggregation pipelines, many index types and $lookup joins
Multi-document ACID transactions with commit and abort
Datasets are not limited by RAM, and native sharding spreads them across servers
MongoDB Atlas runs on AWS, Azure and Google Cloud with a free tier

Limitations

Redis limitations

Dataset size is bounded by memory unless you use a vendor tiering feature such as Redis Cloud auto-tiering
Default persistence can lose minutes (RDB) or about a second (AOF everysec) of writes after an unclean stop
Transactions do not roll back, and Redis Cluster does not guarantee strong consistency
Multi-key operations in Redis Cluster need all keys in the same hash slot
Licensing has changed twice since 2024, which some organisations will need to review

MongoDB limitations

Not designed as a cache, message broker or rate limiter; a separate store is usually added for those jobs
Documents are capped at 16 MiB; larger objects need GridFS
SSPL is not an OSI-approved licence
Sharding and replica sets add operational work when self-managed

When to choose each

Choose Redis if

You need a cache in front of a slower database, including MongoDB
You store sessions, tokens, rate-limit counters or feature flags with expiry
You need leaderboards, real-time counters or queues built on sorted sets, lists or streams
You want fast JSON or vector search over a dataset that comfortably fits in memory

Choose MongoDB if

You need the primary, durable store for application records
Your data is larger than the memory you want to pay for
You query the same data in many ways and need aggregation and indexing
You need multi-document transactions that roll back on failure
You want a vendor-run service with a free tier across three major clouds

When neither is right

Relational data with many joins, foreign keys and reporting needs: a relational database fits better; see MongoDB vs PostgreSQL and SQL vs NoSQL.
Very high write volume across many data centres with tunable consistency: a wide-column store may suit; see Cassandra vs MongoDB.
A serverless key-value store fully inside AWS with pay-per-request pricing: see DynamoDB vs MongoDB.
Durable event streaming with long retention and replay is the job of a dedicated log or message broker rather than either product.

Final recommendation

Bottom line

Treat this as a question of roles rather than a contest. MongoDB is the better primary database for most applications that need durable, queryable records, because it writes to disk by default, is not bounded by RAM and supports transactions that roll back. Redis is the better tool for data that must be fast and can be rebuilt or tolerate a small loss window: caches, sessions, counters, queues and real-time features. Redis 8's JSON and search features narrow the gap for in-memory datasets, but in our view they make Redis a stronger companion to MongoDB rather than a replacement for it.

Frequently asked questions

Can Redis replace MongoDB?

For small datasets that fit in memory and can tolerate Redis's persistence trade-offs, Redis 8 with JSON and Redis Search can serve as a document store. For most systems of record, no: Redis's documentation describes data loss windows for RDB and AOF, transactions without rollback, and a cluster mode without a strong consistency guarantee. MongoDB is designed for durable storage of data larger than RAM.

Should I use Redis and MongoDB together?

Often, yes. A common design keeps records in MongoDB and uses Redis as a cache (cache-aside with an expiry), a session store, a rate limiter or a queue. The application must handle cache invalidation when MongoDB data changes.

Is Redis open source again?

According to Redis's licence page, Redis 8.0 and later can be used under AGPLv3, which is OSI-approved, as well as RSALv2 or SSPLv1. Redis 7.4 to 7.8 were RSALv2 or SSPLv1 only, and 7.2 and earlier were BSD-3-Clause.

What is Valkey?

Valkey is a Linux Foundation project that forked Redis 7.2.4 in March 2024 and continues under the BSD 3-clause licence. It is a separate code base, so check its own documentation for feature support rather than assuming parity with Redis 8.

Does Redis lose data on restart?

Only if persistence is off or the last writes were not yet saved. With RDB snapshots the documentation says to be prepared to lose the latest minutes of data after an unclean stop; with AOF and the default fsync-every-second policy, about one second. Using both RDB and AOF is Redis's suggestion for stronger safety.

Sources

Checked October 2026.

How we research comparisons: our editorial method.