Redis Forks & Alternatives
Since Redis Inc. relicensed away from BSD in March 2024, the ecosystem of Redis-compatible servers has fragmented. Valkey is the Linux Foundation fork preserving the BSD lineage with new development. Dragonfly is a from-scratch C++ reimplementation that scales linearly across cores. KeyDB was the first multi-threaded fork, now lower energy after Snap's acquisition. Garnet is Microsoft Research's C# RESP-compatible server. All five speak (mostly) the same wire protocol, but their internal architectures, performance profiles, and maturity differ sharply. This page compares the five on the dimensions that actually matter for production.
Threading Models Compared
Key Numbers (memtier on 16-core hosts, vendor claims)
Why So Many Forks Now
Redis (the original)
Single-threaded reactor, RSAL+SSPL since 2024.
Redis OSS — the codebase Salvatore Sanfilippo wrote starting in 2009 — defines the wire protocol, the command set, and the internal data structures everyone copies. Single-threaded command execution, BSD until March 2024, now RSAL+SSPL for 7.4+. Redis Stack adds search, JSON, time-series, vector similarity as proprietary modules.
Strengths: most mature, best library support, decades of battle-testing. Weaknesses: per-core ceiling, license uncertainty for cloud providers, slower release of multi-core improvements than the forks.
Valkey (BSD continuation)
Linux Foundation fork at the last BSD commit; neutral governance.
Valkey was created days after Redis's relicense. The first release (7.2.5) was bit-for-bit compatible with Redis 7.2. Active development under the Linux Foundation with maintainers from AWS, Google, Oracle, Ericsson, and others. Valkey 8.0 (late 2024) introduced async I/O improvements and lock-free expanded data structures, claiming roughly 3x throughput over Redis OSS at the time on equivalent hardware.
AWS ElastiCache, Memorystore, and other cloud Redis-compatible services have adopted Valkey as their backing implementation. For new deployments, Valkey is the safe choice if you want the Redis programming model with permissive licensing.
Dragonfly (from-scratch C++)
A modern reimplementation focusing on multi-core scaling.
DragonflyDB is a 2022-launched commercial open-source database (BSL with conversion to Apache 2.0 after 4 years). Architecture: a shared-nothing per-core sharding scheme — each core owns a subset of the keyspace, no shared structures, no locks on the hot path. Cross-shard transactions use VLL (Very Lightweight Locking) — a simple two-phase locking protocol that scales to many cores.
Key architecture choices: hopscotch hashtable for per-shard storage (cache-friendly, O(1) without large pointer indirection), a single binary running on all cores, RESP2/RESP3 compatibility, partial Redis Cluster support (with their own gossip variant). Their benchmarks claim 3.8M ops/s on a 16-core c6gn.4xlarge — about 15x stock Redis on the same hardware.
Compatibility: ~99% but not 100%. Some commands have subtle behavior differences (notably around expiration in the face of cluster operations and around Lua determinism). Pub/sub semantics differ slightly. For straightforward key-value workloads, drop-in.
KeyDB (lock-shared multithreaded)
First multithreaded Redis fork, now slower-moving.
KeyDB started as a Redis fork in 2019 with the aim of multi-threading. Architecture: N worker threads share a single keyspace dict protected by per-bucket spinlocks. Multi-master replication is the headline differentiator — two KeyDB nodes can both accept writes and replicate to each other (with last-writer-wins on conflicts).
Snap acquired KeyDB Software in 2022. Open-source development continues but at a reduced pace; the bigger-picture differentiator (multi-master, multithreading) is partially eclipsed by Valkey's incremental multithreading and Dragonfly's shared-nothing design. Still a viable production option if you specifically need multi-master.
Garnet (Microsoft Research C#)
A research-grade RESP server in C# with FASTER as the storage backend.
Released by MSR in March 2024 under the MIT license. Implements the RESP wire protocol on top of the FASTER key-value store (their earlier research project — log-structured, with hybrid memory/disk tiering and lock-free hot paths). Garnet supports a subset of Redis commands: strings, lists, sets, sorted sets, hashes, plus its own extensions.
The pitch: very high throughput on modern hardware leveraging C#'s async runtime and FASTER's tiering. Microsoft uses it internally for Azure features. For .NET shops with compatible workloads it's interesting; for general use the surface coverage and ecosystem lag matter.
Comparison Matrix
| Feature | Redis | Valkey | Dragonfly | KeyDB | Garnet |
|---|---|---|---|---|---|
| License | RSAL/SSPL | BSD-3 | BSL→Apache | BSD-3 | MIT |
| Threading | 1 main + bg | 1 main + I/O | shared-nothing N | N + locks | async tasks |
| 16-core perf | ~250k ops/s | ~700k | ~3.8M | ~1.0M | ~2.5M |
| Cluster mode | native | native | partial | partial | none |
| Multi-master | no | no | no | yes | no |
| Tiered storage | no | no | experimental | FLASH | yes (FASTER) |
| Maturity | highest | high | medium-high | medium | low |
FAQ
What's the actual performance gap?
On a 16-core box, Dragonfly claims ~3.8M ops/sec on memtier_benchmark vs Redis at ~250k ops/sec — about 15x. The gap is real but workload-dependent: small GET/SET dominate Dragonfly's lead because the bottleneck is wire I/O and command dispatch, both of which scale across cores in Dragonfly. For workloads dominated by complex commands (large ZADD, EVAL with significant Lua time, SORT), the ratio narrows because per-command CPU cost is the bottleneck either way.
Is Valkey a fork or a continuation?
It's officially a continuation. When Redis Inc. relicensed Redis from BSD to RSAL/SSPL in March 2024, the Linux Foundation forked the last BSD-licensed commit and named it Valkey. The maintainers include former Redis maintainers from AWS, Google, and Oracle. Valkey 7.2 is line-for-line compatible with the Redis it forked from; Valkey 8.0+ adds new features like multi-threaded I/O paths beyond what Redis OSS had. AWS ElastiCache and most cloud providers shifted to offering Valkey as their default 'Redis-compatible' option.
How does Dragonfly avoid Redis's data-structure incompatibilities?
Dragonfly reimplements every data structure from scratch in C++ rather than using Redis's source. They cite this as why they could remove Redis's Big-O footguns (HGETALL on a 10M hash is fast in Dragonfly because they use a hopscotch hashtable; in Redis it's a single-thread-blocking O(n) scan). The cost: subtle behavioral differences. For example, Dragonfly's pub/sub semantics differ slightly under partition; cluster failover protocols don't fully match Redis Cluster's gossip. Drop-in compatibility is ~99% but not 100%.
What is KeyDB's place now?
KeyDB was the first multithreaded Redis fork (2019), gaining attention for its 'multi-master' mode and active replication. Snap acquired it in 2022 and integration there was the focus; the open-source repo has slowed. With Valkey now offering multithreading natively (or via the io-threads expansion), KeyDB's differentiation is reduced. Still a viable fork for production but the ecosystem energy moved.
Is Garnet a Redis-compatible server?
Yes. Microsoft Research released Garnet in 2024 — a C# server speaking the RESP wire protocol. Designed for very high throughput on modern hardware with C#'s async runtime. Compatibility is a moving target; Garnet implements core string/hash/set/list ops but not the full Redis surface. Interesting for .NET shops with workloads that fit; not a drop-in for arbitrary Redis use.
Should I migrate from Redis to Dragonfly?
If you're CPU-bound on a single Redis instance, yes — the core scaling is the headline win. Test your specific commands first; complex scripts, transactions with WATCH/MULTI, and cluster operations have the most behavioral risk. If you're not CPU-bound (most caching workloads aren't — they're memory-bandwidth or network-bound), the speedup is smaller and Redis's mature ecosystem (libraries, tooling, ops experience) often wins on TCO.