I’ve now run the same sorted set benchmark twice on Valkey: 50 million members pushed into a single ZSET via pipelined ZADD, memory measured at the end. The first post documented Valkey 8.1 cutting memory 22% versus 8.0. The follow-up found another 11% in Valkey 9.1. The obvious next question: what does the same test look like on Redis?
I wanted a reproducible benchmark to assess the progress through the builds. Here is the same benchmark, same tool (sorted-set-benchmark, pipelined ZADD NX, members m:{i}, integer scores), same Graviton4 box (r8g.4xlarge), same protocol: ten repetitions per version with a flush in between, official docker images with --save '' --appendonly no, one server at a time, single benchmark client on the same host. Six Redis versions, five Valkey versions.
The numbers
Memory and insert throughput by engine and version
| Engine | Version | used_memory | Bytes per member | Median inserts/sec |
|---|---|---|---|---|
| Redis | 7.4.11 | 4.83 GB | ~97 | 539k/s |
| Redis | 8.0.6 | 4.83 GB | ~97 | 544k/s |
| Redis | 8.2.10 | 4.83 GB | ~97 | 551k/s |
| Redis | 8.4.7 | 4.83 GB | ~97 | 536k/s |
| Redis | 8.6.7 | 3.73 GB | ~75 | 613k/s |
| Redis | 8.10.2 | 3.73 GB | ~75 | 632k/s |
| Valkey | 7.2.14 | 4.83 GB | ~97 | 516k/s |
| Valkey | 8.0.11 | 4.83 GB | ~97 | 533k/s |
| Valkey | 8.1.10 | 3.77 GB | ~75 | 590k/s |
| Valkey | 9.0.6 | 3.77 GB | ~75 | 571k/s |
| Valkey | 9.1.2 | 3.34 GB | ~67 | 647k/s |
Memory figures are the server’s used_memory (decimal GB, as the tool reports it). Every version’s ten repetitions landed on the same value at the tool’s reporting precision, roughly 10 MB granularity, with mem_fragmentation_ratio at 1.01x throughout, so RSS tracks these numbers closely. Throughput spreads across the ten runs were tight; the two headline configurations don’t overlap (Valkey 9.1: 643 to 652k/s; Redis 8.10: 628 to 639k/s).
Three things stand out. First, every version of both engines that predates this optimization work sits at the same 4.83 GB for this workload, which is what you’d expect given the shared codebase history of the ZSET implementation. Second, Redis ships a comparable reduction: memory drops from 4.83 GB to 3.73 GB, 23%, exactly at the 8.6 boundary (8.4.7 has the old layout, 8.6.7 the new one), with median inserts rising from 536k/s to 613k/s. Third, Valkey 9.1.2 remains the smallest and fastest configuration I tested: about 10% less memory than Redis 8.10.2 and a small but consistent throughput edge.
The same idea, traveling
I found it really interesting that Redis’s newest number lands within one percent of Valkey 8.1’s: 3.73 GB versus 3.77, about 75 bytes per member either way. Redis in late 2026 is, byte for byte, roughly Valkey of April 2025. That’s not a coincidence, and you can trace exactly why through public pull requests and release notes.
Valkey PR #1427 (merged January 2025, shipped in Valkey 8.1 that April) restructured the sorted set so the hash lookup structure points directly at the skiplist node, instead of keeping its own copy of the mapping. In this benchmark that’s the 4.83 to 3.77 GB step. Valkey PR #2508 (merged November 2025, shipped in 9.1) then embedded the member string inside the skiplist node itself, removing a pointer and a separate allocation per element. That’s the 3.77 to 3.34 GB step.
Redis PR #14701 (merged January 2026, a year and ten days after Valkey’s) copied this work to Redis, and the PR description says where it came from, verbatim: “This is based on: valkey-io/valkey/pull/1427.” Credit to the engineer for saying so plainly; not everyone does. The adaptation kept Redis’s dict (in no_value mode) instead of adopting Valkey’s new hashtable, grafted on the node embedding, and shipped in Redis 8.6. My measurements agree with their release notes: the drop lands exactly at 8.6.
So why is Redis still 10% behind? Because copying is a trailing indicator. Redis took the design but not the hashtable it was built on, and by the time the port shipped, Valkey had already taken the next step. That’s the whole gap: the piece of the design they didn’t adopt, plus the release they haven’t caught up to yet. I mean this without a drop of snark toward the engineer who did the work: Valkey is BSD licensed precisely so anyone, including Redis, can build on it, and Redis users are genuinely better off for it. If the ideas flowed the other way, I’d report that too. But I benchmark what shipped, and what shipped says one project is setting the pace on this data structure and the other is matching it, about a year behind.
The operator’s takeaway
Same caveats as always: one large skiplist-encoded ZSET, short members, integer scores, allocator-level accounting, a single pipelined client. Your data shape will land somewhere else, so run the tool against your own workload.
If you run Valkey, this is simple: 9.1 posted the lowest memory and the highest insert rate of everything on this table, and the upgrade is the whole optimization. I’ll keep running this benchmark as both projects ship.
If you run Redis and are worried that Valkey is more efficient, you have two options. You can wait for Redis to eventually copy the latest Valkey PR, or you can switch to Valkey. What do you plan to do?
Momento Cache: the fastest Valkey in the cloud
You always get the latest Valkey through Momento’s managed services, without managing the infrastructure yourself. Momento smoothly handles upgrades, failover, optimization, and more with the same technology that powers some of the world’s largest caches. Join companies like Snap, Coinbase, Paramount, and Capcom: try Momento Cache now!
