Redis vs Memcached vs Dragonfly vs KeyDB: Caching Solutions 2025

Choosing a caching layer in 2025 is not what it was in 2015. Redis is no longer the obvious default—Dragonfly promises to replace it with 25× the throughput, KeyDB adds multi-master replication, and Memcached is still quietly beating everyone on pure simplicity benchmarks. The landscape is genuinely competitive.

This guide cuts through the marketing and gives you the data you need: architecture trade-offs, benchmark numbers, licensing realities, and a concrete decision framework. By the end you will know exactly which system belongs in your stack.

Before you dive in: open the Redis CLI Simulator in another tab to experiment with Redis commands hands-on as you read.

Quick Comparison Table

Feature	Redis 7.x	Memcached 1.6	Dragonfly 1.x	KeyDB 6.x
Data types	Rich (strings, hashes, lists, sets, sorted sets, streams, JSON)	Strings only	Redis-compatible (full)	Redis-compatible (full)
Persistence	RDB + AOF	None	RDB + AOF	RDB + AOF
Clustering	Redis Cluster (hash slots)	Client-side sharding	Built-in (no slots)	Active-Replication
Throughput (ops/sec)	~1M (single-thread)	~1.5M (multi-thread)	~25M (multi-thread)	~2–5M (multi-thread)
Memory efficiency	Moderate	High	High (Dashtable)	Moderate
Multi-threading	No (single event loop)	Yes	Yes	Yes
Pub/Sub	Yes	No	Yes	Yes
Lua scripting	Yes	No	Yes (limited)	Yes
License	RSALv2 / SSPL	BSD	BSL 1.1	BSD
Drop-in replacement	—	No	Yes	Yes

The licensing row matters in 2025. Redis changed to RSALv2 + SSPL in 2024, which restricts cloud providers from offering Redis as a managed service without a commercial agreement. Dragonfly uses BSL 1.1 (source-available, converts to Apache 2.0 after four years). KeyDB remains BSD. If open-source licensing is a hard requirement for your org, Memcached and KeyDB are your safest bets.

Redis Deep Dive

Redis is the reference implementation. Every other tool in this list is measured against it.

What makes Redis special

Redis earned its dominance through data structure richness. You can store sorted sets for leaderboards, streams for event sourcing, hyperloglogs for approximate cardinality counting, and geospatial indexes—all in a single process with sub-millisecond latency.

# Sorted set for a game leaderboard
ZADD leaderboard 9823 "alice"
ZADD leaderboard 8741 "bob"
ZREVRANGE leaderboard 0 9 WITHSCORES

# Stream for event sourcing
XADD events * action "purchase" user_id "u_123" amount "49.99"
XREAD COUNT 100 STREAMS events 0

Persistence options

Redis gives you two persistence mechanisms, and you can run both simultaneously:

RDB (snapshot): point-in-time snapshots. Fast restarts, slightly stale on crash.
AOF (append-only file): logs every write command. Up to 1-second durability with appendfsync everysec.

For most applications, appendfsync everysec with AOF rewrite gives the right balance of durability and performance.

Redis Stack

Redis 7+ includes Redis Stack modules: RedisJSON (native JSON), RediSearch (full-text + vector search), RedisTimeSeries, and RedisBloom. If you are building a search layer or vector database on top of your cache, Redis Stack eliminates an entire service from your architecture.

The single-thread limitation

Redis processes commands on a single event loop thread. This is intentional—it eliminates locking overhead and makes Redis commands atomically safe. The downside: you cannot saturate a modern 32-core server with a single Redis instance. You need to shard across multiple instances or use Redis Cluster.

Best for: applications that need rich data structures, pub/sub, Lua scripting, or the Redis Stack ecosystem. Mature operational tooling (Redis Sentinel, Cluster, client libraries in every language).

Memcached Deep Dive

Memcached is 20 years old and still relevant. That tells you something.

Pure caching, no surprises

Memcached does exactly one thing: store key-value pairs with a TTL. No persistence, no replication, no pub/sub, no scripting. What it gains from that simplicity is raw throughput and exceptional memory efficiency.

# That's basically the entire API
set user:123 0 3600 48
{"id":123,"name":"Alice","email":"[email protected]"}

get user:123

Multi-threaded architecture

Unlike Redis, Memcached uses a thread-per-CPU model. On a 16-core machine, Memcached scales linearly. Benchmarks consistently show Memcached outperforming Redis on raw GET/SET throughput when the workload is simple strings and you have multiple CPU cores available.

When Memcached beats Redis

Extremely high-throughput read workloads (CDN edge caching, session stores with millions of concurrent users)
Memory-sensitive environments: Memcached’s slab allocator wastes less memory than Redis’s per-object overhead
Operational simplicity: no persistence configuration, no AOF corruption to recover from, no replication to set up
Regulatory/compliance: BSD license, zero concerns about SSPL or BSL

Best for: high-traffic read-heavy caches where data can be rebuilt from the source of truth. Session stores. Fragment caching in Rails or Django. Anywhere you want a fast, dumb cache with zero operational overhead.

Dragonfly Deep Dive

Dragonfly is the most technically interesting entrant in this comparison. It was built from scratch in 2022 with one goal: be a drop-in Redis replacement that uses all your CPU cores.

The architecture difference

Redis runs on one thread. Dragonfly runs on N threads, one per CPU core, using a shared-nothing architecture inspired by the Seastar framework. Each thread owns a slice of the keyspace. Inter-thread coordination uses a lock-free algorithm called Dashtable that avoids the contention that kills most multi-threaded approaches.

The result: on a 64-core machine, Dragonfly has benchmarked at over 25 million ops/sec on GET/SET—roughly 25× a single Redis instance.

Drop-in compatibility

Dragonfly speaks the Redis Serialization Protocol (RESP). Your existing Redis clients (redis-py, ioredis, Jedis, StackExchange.Redis) connect to Dragonfly without code changes. Dragonfly passes >99% of the Redis compatibility test suite.

# Zero code changes — just point to Dragonfly's port
redis-cli -h dragonfly-host -p 6379 SET key value

What is missing

Dragonfly is not complete Redis. As of 2025:

Lua scripting support is limited (basic EVAL works, complex scripts may not)
Redis Modules / Redis Stack are not supported
Redis Cluster protocol is different (Dragonfly has its own clustering)
Some administrative commands behave differently

The BSL license

Dragonfly uses Business Source License 1.1: source-available, converts to Apache 2.0 after four years. You can run Dragonfly in production, self-hosted, without restrictions. The BSL only restricts competitors from offering Dragonfly as a managed service.

Best for: replacing Redis in high-throughput applications where you want vertical scalability (one big instance instead of a sharded cluster). Batch processing, real-time analytics, game backends with thousands of concurrent writers.

KeyDB Deep Dive

KeyDB is a Redis fork maintained by Snap (originally EQ Alpha). It predates Dragonfly and takes a different approach to multi-threading.

Multi-threading via a different model

KeyDB introduces a multi-threaded event loop where multiple threads can execute read commands concurrently and write commands are serialized with fine-grained locking. On read-heavy workloads, this delivers 2–5× Redis throughput on the same hardware.

Active-Replication (the killer feature)

KeyDB’s standout feature is Active-Active Replication: every replica can accept writes, and changes replicate bidirectionally. This means you can distribute write traffic across multiple KeyDB nodes without complex sharding logic.

Node A (write) ←→ Node B (write)
      ↓                 ↓
   Clients           Clients

For global applications that need low-latency writes from multiple regions, KeyDB’s active replication is operationally simpler than Redis Cluster or manual sharding.

Flash storage support

KeyDB supports storing cold data on NVMe SSDs (KeyDB on Flash), keeping hot data in RAM. This can reduce RAM requirements by 3–5× for large datasets with uneven access patterns.

Best for: globally distributed applications requiring multi-region active writes. Large datasets where memory cost is a constraint (Flash mode). Teams that want Redis compatibility + multi-threading without Dragonfly’s licensing considerations.

Performance Benchmarks

These numbers are from independent benchmarks (2024–2025). Hardware varies—treat these as relative indicators, not absolute guarantees.

Single-node GET/SET throughput (8-core server, 64-byte values)

System	GET ops/sec	SET ops/sec
Redis 7.2	~800,000	~750,000
Memcached 1.6	~1,400,000	~1,200,000
Dragonfly 1.x	~12,000,000	~10,000,000
KeyDB 6.3	~2,200,000	~1,800,000

Memory overhead (1 million string keys, 64-byte values)

System	RAM usage
Redis	~180 MB
Memcached	~120 MB
Dragonfly	~130 MB
KeyDB	~175 MB

Memcached’s memory efficiency advantage is real—its slab allocator avoids per-key overhead that Redis accumulates at scale.

Use Case Decision Guide

Session cache (millions of concurrent users)

Winner: Memcached or Dragonfly

Session data is strings. You need massive concurrent reads with moderate writes. Memcached handles this with zero configuration. Dragonfly handles it with more headroom for growth.

Real-time leaderboard

Winner: Redis or KeyDB

Sorted sets are the right data structure. ZADD/ZREVRANGE/ZRANK are purpose-built for leaderboards. Use Redis unless you need multi-region active writes (then KeyDB).

Pub/Sub messaging

Winner: Redis

Redis pub/sub is battle-tested. Redis Streams (XADD/XREAD with consumer groups) is a proper message queue implementation. Dragonfly supports basic pub/sub but not Streams fully.

High-throughput ingestion (IoT, analytics, event tracking)

Winner: Dragonfly

If you are writing millions of events per second from many producers, Dragonfly’s multi-threaded architecture absorbs write bursts that would queue up against Redis’s single event loop.

Simplicity / operational minimalism

Winner: Memcached

No AOF, no RDB, no replication config, no Lua, no modules. Start it, use it, stop it. Nothing to tune.

Multi-region active writes

Winner: KeyDB

Active-Active replication without sharding complexity.

Migration Considerations: Redis to Dragonfly (Zero Downtime)

Dragonfly’s RESP compatibility makes migration straightforward:

Step 1: Deploy Dragonfly alongside Redis

# docker-compose.yml
services:
  redis:
    image: redis:7
    ports: ["6379:6379"]
  dragonfly:
    image: docker.dragonflydb.io/dragonflydb/dragonfly
    ports: ["6380:6379"]

Step 2: Use REPLICAOF to sync data

# On Dragonfly, replicate from Redis
redis-cli -p 6380 REPLICAOF redis 6379

Dragonfly will pull all existing keys from Redis. Monitor with INFO replication until master_sync_in_progress: 0.

Step 3: Flip traffic

Update your connection string from port 6379 to 6380. No application code changes needed.

Step 4: Verify and remove Redis

Run both in parallel for 24 hours, monitor error rates, then decommission Redis.

Caveats: If you use Redis Modules, Redis Cluster protocol, or complex Lua scripts, audit those before migration—they may not work on Dragonfly.

FAQ

Q: Can I use Dragonfly in production today?

Yes. Dragonfly is production-stable as of 2024. Companies like Hyundai, Snap, and various startups run it in production. The primary risk areas are Redis Module compatibility and complex Lua scripts.

Q: Does the Redis license change affect self-hosted Redis?

No. RSALv2 + SSPL restricts cloud providers who want to offer Redis as a managed service. Self-hosting Redis for your own application is unaffected—it is still free to use.

Q: Is Memcached still being actively developed?

Yes. Memcached 1.6.x (2024) added TLS support, improved stats, and extstore (SSD tiering). The project is actively maintained, just slow-moving because it does not need to add features.

Q: Can KeyDB replace Redis Sentinel?

KeyDB’s active replication handles HA differently than Sentinel. You get active-active writes instead of passive failover. Most Sentinel use cases (HA for a single primary) can be covered by KeyDB’s replication, but the operational model is different—read the KeyDB docs before migrating.

Q: Which caching solution has the best client library support?

Redis has the broadest ecosystem. Dragonfly and KeyDB are RESP-compatible, so all Redis clients work with them. Memcached has its own protocol—most languages have Memcached client libraries (libmemcached, pymemcache, etc.) but the ecosystem is smaller than Redis.

Conclusion

Here is the honest summary:

Default choice for most applications: Redis. Rich data structures, mature tooling, and the widest ecosystem.
Highest raw throughput: Dragonfly. If you are bandwidth-constrained on a single Redis instance, Dragonfly is the most compelling upgrade path—same protocol, 10–25× throughput.
Simplicity and memory efficiency: Memcached. Still unbeatable if all you need is a fast string cache.
Multi-region active writes: KeyDB. Active-Active replication without sharding complexity.
Open-source license requirement: Memcached (BSD) or KeyDB (BSD). Dragonfly (BSL 1.1) is source-available. Redis (RSALv2+SSPL) restricts managed service providers.

The era of Redis being the automatic default for all caching is over. Dragonfly has real production traction and the benchmark numbers are not marketing—they are measured. For new high-throughput systems in 2025, running a quick Dragonfly evaluation before defaulting to Redis is worth the 30 minutes it takes.

Experiment with Redis commands directly in the Redis CLI Simulator to build muscle memory before committing to any architecture decision.