Valkey explained: choosing between Redis and Dragonfly

The March 2024 decision by Redis Ltd to change the Redis license from BSD to a dual RSALv2/SSPLv1 model fundamentally changed the in-memory database landscape. This change meant cloud providers could no longer offer managed Redis services without entering expensive commercial agreements. The Linux Foundation responded by creating Valkey, a fork of Redis 7.2.4 that uses the permissive BSD 3-Clause license. Since the fork, Valkey 8.0 reached 1.19M RPS on a single node, representing a 230% throughput increase over the 7.2 version. Valkey 8.1 also includes a new hash table that improves memory efficiency by 20% for workloads with many small keys, which translates to a 16% reduction in RAM for 100 million string keys compared to Redis 7.2. Because Valkey maintains wire-protocol compatibility, existing Redis clients connect without code changes. AWS, Google Cloud, and Oracle support Valkey through services like ElastiCache and Memorystore. Redis 8.0 later introduced the AGPLv3 license in May 2025, but this license imposes copyleft obligations for network services that may affect SaaS providers. Fedora Linux 41 even proposed replacing Redis with Valkey to maintain FOSS principles.

Architectural Performance and Throughput

Architectural designs determine how these engines handle high-concurrency workloads. Redis and Valkey use a single-threaded model for command execution, though they offload network I/O to background threads. In a 4 vCPU, 16 GB Ubuntu runner test, DragonflyDB reached 494,248 ops/s for small writes, whereas Redis achieved 452,812 ops/s and Valkey reached 432,825 ops/s, showing how the multi-threaded architecture of DragonflyDB provides a clear advantage for write-heavy workloads. Valkey leads in pipelined batches with 1,461,472 ops/s, which is 23.9% higher than the 1,179,179 ops/s from Redis 8.4.0. However, Valkey pays for this pipelining advantage with higher un-pipelined latency, recording a hot-read p95 of 1.191 ms against the 0.607 ms from Redis 8.4.0. DragonflyDB manages memory more efficiently during snapshots because it uses io_uring for async I/O, avoiding the memory spikes that Redis experiences during BGSAVE. For hot-key reads, the spread measures protocol and I/O-path overhead rather than data-structure speed. KeyDB provides the most specialized messaging performance with a Pub/Sub p95 latency of 0.557 ms.

Selection Strategies for Production

Choosing the correct engine requires an assessment of specific production requirements. Redis remains the standard for teams that require the full Redis Stack module ecosystem, such as RediSearch or RedisTimeSeries. These features do not have identical, first-party equivalents in Valkey yet. DragonflyDB is the optimal choice for vertical scaling, as a single instance can replace a sharded Redis cluster by providing up to 3.8 million QPS on a single node. Because DragonflyDB uses io_uring, its memory usage stays flat during snapshots, unlike Redis which can see memory usage triple due to copy-on-write. Valkey is the most practical choice for new caching layers on AWS or Google Cloud due to its performance and 20% lower cost on ElastiCache. Migration from Redis to Valkey remains easy because the two engines share 90% command-level compatibility. If you are managing a large-scale cluster, you must account for the different scaling behaviors of these engines. Will Valkey eventually achieve full feature parity with the Redis Stack module ecosystem?