Valkey 9.1 cuts per-key string overhead by 17 to 44 percent with no config change

The 2.1 million requests per second is a Valkey dashboard figure, measured on a single server with 512-byte payloads ^[13]. For it to describe your cache, your payloads have to sit near that size and your host has to have the cores the redesigned I/O threading model can use. The component figures are narrower than the total. Up to 17 percent of the throughput gain is credited to the threading redesign, and the 25 percent latency reduction is credited to Multipath TCP support ^[13]. If MPTCP is not in use on the path between client and server, that 25 percent does not apply to you.

The memory figure is the one you can check against your own keyspace before migrating. Valkey reports per-key overhead on string keys falling by 17 to 44 percent, averaging about 26 percent, with no configuration changes ^[11]. Overhead is charged per key, so the saving scales with key count and not with how much data each key holds. Sorted set members save up to 8.5 bytes each ^[12]. On a set with ten million members, that is at most 85 megabytes ^[23].

Redis 8.4's numbers are scoped to search and JSON workloads. Multi-threaded query I/O gave up to 4.7x throughput on FT.SEARCH workloads returning large result sets ^[18], which transfers only to the extent that your instance runs FT.SEARCH at all. The 91 percent memory reduction is scoped to homogeneous JSON arrays ^[19]. VADD and VSIM picked up AVX2 and AVX512 dot product implementations, so vector work now depends on what instruction set your hosts expose ^[16]. SET gained IFEQ and IFNE, which update a key only if its value has not changed since you fetched it, in one command ^[17].

Numbered databases now work in sharded Valkey clusters, which the write-up says makes multi-tenancy on one cluster practical instead of one instance per tenant ^[8]. Redis has matched one of the seven Valkey advances the write-up lists: atomic slot migration, which Valkey 9.0 shipped first using the AOF format instead of copying key by key, and which Redis added in 8.4 ^[7][24].

The comparison is one engineer's research summary. The author discloses JVM backend work, six years of Spring Boot, no Valkey-to-Redis migration of his own, and Redis running in his own AI agent infrastructure ^[21]. He read the release notes on both sides, Valkey's benchmark dashboards, the security advisories, and an independent benchmark he says caught a trap in Valkey's own docs ^[20]; the text breaks off before that benchmark is described ^[25]. The license change that started the waiting was March 2024, when Valkey was close to Redis 7.4 with different governance ^[1][2]. In the author's framing, Redis 8.4 bets that the cache becomes the retrieval layer for AI applications, and Valkey 9.1 bets that the cache stays a cache and gets cheaper and faster at it ^[22].