Software & Apps

Valkey 8.0 performance and the managed service shift

Valkey 8.1.1 achieves 999.8K RPS on SETs with 0.8ms p99 latency, outperforming Redis 8.0 on Graviton4 hardware. Managed services like AWS ElastiCache for Valkey offer 33% lower pricing for Serverless compared to previous Redis options.

Valkey 8.0 performance and the managed service shift

Threading and throughput gains

Valkey 8.1.1 achieves 999.8K RPS on SETs with 0.8ms p99 latency on a c8g.2xl instance. Redis 8.0 reaches 729.4 RPS on SETs with 0.99ms p99 latency on that same hardware. Valkey delivers 37% higher SET throughput and 16% higher GET throughput. Valkey p99 latency for SET is 30% faster and 60% faster for GET. Valkey 8.0 introduced a dual-channel replication scheme that reduces synchronization time by 50% in read-heavy scenarios by using a dedicated connection for RDB transfer to free the primary process for client queries while maintaining better write latency. While both platforms use asynchronous I/O threading to handle network tasks, Valkey 8.0 pulls ahead when scaling across multiple cores. Valkey 8.0 demonstrated a 230% increase in throughput over Valkey 7.2 when benchmarked on an AWS c7g.4xlarge instance. Redis 8.0 improves its own performance by setting the io-threads parameter to 8 on a multi-core Intel CPU, which increases throughput by up to 112%. Redis 8.0 also uses dual-stream replication to handle writes 7.5% faster during synchronization and complete the process 18% faster. I find the Valkey 8.1.1 performance gains on Graviton4 hardware to be the clearest evidence of its trajectory.

Managed service shifts and licensing

AWS ElastiCache for Valkey provides 33% lower pricing for Serverless and 20% lower pricing for self-designed clusters. Users create a cache in under a minute starting at $6 per month. This service provides 99.99% availability and microsecond latency. MemoryDB for Valkey provides 30% lower pricing than Redis OSS. These managed options arrived in October 2024. Redis 7.4 and subsequent versions utilize RSALv2 and SSPLv1, while Redis 8.0 adds AGPLv3. Valkey maintains the BSD-3-Clause license. You already know that license shifts drive these infrastructure moves. Redis 7.2 and earlier versions remain under the BSD-3-Clause license until December 1, 2029. Even though the move to SSPL and AGPL caused controversy, Redis maintains the right to change its license for its own contributions. Google Cloud offers Memorystore for Valkey, and Alibaba Cloud provides a complete suite of services. AWS also scales to 500M requests per second.

Feature Valkey 8.1 Redis 8.0
License BSD-3-Clause RSALv2, SSPLv1, AGPLv3
JSON Support Yes Yes
Bloom Filter Yes Yes
Vector Sets No Yes

Dragonfly and efficiency

Dragonfly uses the BSL 1.1 license and requires no code changes for Redis API compatibility. A single Dragonfly instance handles 4M+ ops/sec. Dragonfly uses 30% less memory than Redis in an idle state. Redis 8.0 includes vector sets and probabilistic data structures. Valkey 8.1 includes JSON and Bloom filter support. Valkey 9.2.0-rc1 adds Path Hash, a radix-tree-backed data type, and ACL roles. Valkey 9.2.0-rc1 also adds XACKDEL and XDELEX stream commands and server-side hot key detection. Dragonfly delivers 25X more throughput than legacy in-memory stores. Dragonfly uses a shared-nothing architecture where each thread owns a subset of the keyspace. This design eliminates locks between threads for most operations. On a c6gn.16xlarge instance, Dragonfly reached 10M QPS for SET and 15M QPS for GET operations in pipeline mode. Dragonfly also uses a custom allocator optimized for the workload. Dragonfly shows comparable performance to Redis on an m5.large instance. On an m5.xlarge instance, the performance gap between Dragonfly and Redis increases. While Dragonfly throughput capacity grows with instance size, single-threaded Redis reaches local maxima in terms of performance. At peak usage, Redis memory use increased to almost 3X that of Dragonfly. Dragonfly finished the snapshot faster, within a few seconds. Dragonfly also outperformed Memcached in write workloads on a c6gn.16xlarge instance, though Memcached showed lower latency for reads. Does the lack of AOF support in Dragonfly prevent its adoption in critical write-heavy environments?