Redis 8.10 vs Valkey 9: My Benchmark Results on the Same Hardware
I wanted to compare Redis 8.10 and Valkey 9 under the same conditions before deciding which one to use on a read-heavy server.
There are plenty of Redis vs Valkey benchmarks online, but I was more interested in what happens on my own setup, with the same CPU limits, same networking, same client load and the same configuration.
I used separate Incus containers for Redis and Valkey and ran memtier_benchmark from the host so both servers were tested from the same client machine.
The results were more interesting than I expected. Valkey was clearly faster in some read-heavy workloads, Redis was slightly faster in some write-heavy cases, and pipelining made the difference much larger.
Test setup
Both containers had the same basic resources and configuration.
- 3 CPU cores per container
io-threads 2- 100 concurrent benchmark connections
- 4 memtier threads
- 25 clients per thread
- 1,000,000-key range
- 100-byte values
- 60-second tests
- AOF disabled
- automatic RDB saving disabled during benchmarks
maxmemory-policy noeviction
The relevant configuration was:
appendonly no save "" io-threads 2 hz 10 maxmemory 0 maxmemory-policy noeviction
I originally tested with persistence still enabled, but that caused background RDB saves during large SET tests, so I disabled automatic snapshots on both sides and reran the important tests.
That made the comparison much cleaner.
100% SET
First I tested pure writes.
Redis
- 50,847 SET/sec
- 1.964 ms average latency
- 2.063 ms p50
- 2.815 ms p99
- 4.095 ms p99.9
Valkey
- 49,506 SET/sec
- 2.018 ms average latency
- 2.023 ms p50
- 2.767 ms p99
- 4.223 ms p99.9
Redis was about 2.7% faster here.
The latency numbers were close enough that I would basically call the pure SET test a small Redis win rather than a major difference.
Interestingly, Valkey had slightly better p50 and p99, while Redis had slightly better average latency and p99.9.
100% GET
This was a much more relevant test for a cache or read replica.
All requested keys already existed, so this was a real cache-hit test and not a benchmark of missing keys.
Redis
- 48,726 GET/sec
- 2.050 ms average latency
- 1.879 ms p50
- 3.247 ms p99
- 4.639 ms p99.9
Valkey
- 52,695 GET/sec
- 1.896 ms average latency
- 1.799 ms p50
- 3.263 ms p99
- 4.287 ms p99.9
Valkey was about 8.1% faster in throughput.
It also had lower average latency and slightly better median latency.
The p99 result was basically identical.
For plain GET-heavy traffic, Valkey looked better.
99% GET / 1% SET
Next I moved to a very read-heavy mixed workload.
Redis
- 53,446 total ops/sec
- 52,911 GET/sec
- 535 SET/sec
- 1.869 ms average latency
- 1.791 ms p50
- 3.391 ms p99
- 5.279 ms p99.9
Valkey
- 54,728 total ops/sec
- 54,179 GET/sec
- 548 SET/sec
- 1.826 ms average latency
- 1.767 ms p50
- 3.199 ms p99
- 6.207 ms p99.9
Valkey was about 2.4% faster.
The interesting part was latency. Valkey had better average, p50 and p99 latency, while Redis was better at the extreme p99.9 tail.
So even when one server wins on throughput, that does not necessarily mean it wins every latency percentile.
95% GET / 5% SET
This result surprised me more.
Redis
- 49,061 total ops/sec
- 46,607 GET/sec
- 2,454 SET/sec
- 2.036 ms average latency
- 2.095 ms p50
- 3.935 ms p99
- 4.767 ms p99.9
Valkey
- 56,919 total ops/sec
- 54,072 GET/sec
- 2,847 SET/sec
- 1.755 ms average latency
- 1.695 ms p50
- 2.671 ms p99
- 5.055 ms p99.9
Valkey was around 16% faster overall.
The latency difference was also significant.
Valkey had roughly:
- 14% lower average latency
- 19% lower p50 latency
- 32% lower p99 latency
Redis still had a slightly better p99.9 result, but overall this was a strong Valkey win.
90% GET / 10% SET
At 10% writes, the result flipped.
Redis
- 50,699 total ops/sec
- 45,628 GET/sec
- 5,071 SET/sec
- 1.971 ms average latency
- 1.951 ms p50
- 3.311 ms p99
- 4.767 ms p99.9
Valkey
- 48,476 total ops/sec
- 43,627 GET/sec
- 4,848 SET/sec
- 2.061 ms average latency
- 2.039 ms p50
- 4.991 ms p99
- 7.103 ms p99.9
Redis was about 4.6% faster.
It also had clearly better p99 and p99.9 latency.
This was probably the most useful reminder from the whole test: the winner changes depending on the workload.
If I had only tested 100% GET, I would have concluded Valkey was simply faster.
If I had only tested 90/10 mixed traffic, I might have concluded the opposite.
GET with pipeline depth 10
This was the biggest difference in the benchmark.
I used the same 100 connections but enabled pipeline depth 10.
Redis
- 247,756 GET/sec
- 4.032 ms average latency
- 4.031 ms p50
- 5.599 ms p99
- 8.159 ms p99.9
Valkey
- 384,619 GET/sec
- 2.596 ms average latency
- 2.399 ms p50
- 3.791 ms p99
- 12.031 ms p99.9
Valkey was around 55% faster in throughput.
That is a very large difference.
Valkey also had much better average, p50 and p99 latency.
Redis was better at p99.9, where Valkey had some larger tail spikes.
This is one result I would definitely repeat several times before making a broad claim, simply because a 55% gap is large enough that it deserves extra verification.
Still, in this run, Valkey handled pipelined GET traffic much better.
MGET with 10 keys
I also wanted to test multiple-key reads because many applications do not always fetch one value at a time.
Each MGET command requested 10 existing keys.
Redis
- 45,653 MGET commands/sec
- 456,528 key reads/sec
- 2.187 ms average latency
- 1.975 ms p50
- 4.479 ms p99
- 7.967 ms p99.9
Valkey
- 50,010 MGET commands/sec
- 500,101 key reads/sec
- 1.997 ms average latency
- 1.839 ms p50
- 3.903 ms p99
- 6.047 ms p99.9
Valkey was about 9.5% faster.
It was also better across all the latency numbers in this test.
The p99.9 difference was fairly large:
- Redis: 7.967 ms
- Valkey: 6.047 ms
For applications that batch cache reads with MGET, this is probably more useful than a simple single-key GET benchmark.
Memory usage
Performance is only half the story, so I also loaded the same dataset into both servers and compared memory use.
The test used 1,000,000 keys with 100-byte values.
Valkey
used_memory: 140.22 MB- RSS: 167.72 MB
- memory overhead: 34.84 MB
- dataset memory: 112.19 MB
- fragmentation ratio: 1.20
Redis
used_memory: 152.47 MB- RSS: 178.30 MB
- memory overhead: 42.03 MB
- dataset memory: 117.85 MB
- fragmentation ratio: 1.17
Valkey used about 8% less internal memory.
In raw numbers:
- Valkey: 147,028,360 bytes
- Redis: 159,876,184 bytes
That is about 12.8 MB less memory for one million keys.
Another way to look at it:
- Valkey: about 147 bytes per key
- Redis: about 160 bytes per key
Valkey also had around 17% lower reported memory overhead.
RSS was around 6% lower as well.
Redis had a slightly better fragmentation ratio, but its total RSS was still higher.
Summary
Here is the short version of the tests.
| Workload | Redis | Valkey | Better result |
|---|---|---|---|
| 100% SET | 50.8k ops/s | 49.5k ops/s | Redis |
| 100% GET | 48.7k ops/s | 52.7k ops/s | Valkey |
| 99% GET / 1% SET | 53.4k | 54.7k | Valkey |
| 95% GET / 5% SET | 49.1k | 56.9k | Valkey |
| 90% GET / 10% SET | 50.7k | 48.5k | Redis |
| GET pipeline 10 | 247.8k | 384.6k | Valkey |
| MGET 10 keys | 45.7k cmds/s | 50.0k cmds/s | Valkey |
| Memory, 1M keys | 152.5 MB | 140.2 MB | Valkey |
There is no single winner in every workload.
Redis did slightly better in pure writes and clearly better in the 90/10 mixed workload.
Valkey did better in most of the read-heavy tests, used less memory, and performed particularly well with pipelining and MGET.
What I would choose
Based on these tests, I would lean toward Valkey for a read-heavy cache or replica server.
The reasons are fairly simple:
- higher GET throughput
- better MGET performance
- better results in very read-heavy mixed workloads
- much stronger pipeline performance in this test
- lower memory usage
I would still consider Redis for workloads with a larger write percentage, because Redis performed better once the write ratio increased to 10% and it also had the slight advantage in the pure SET test.
The important part is that Redis and Valkey are close enough in some workloads that using only one benchmark number does not tell the whole story.
If the server is mostly doing reads, Valkey looked better on this hardware.
If the server is handling a meaningful amount of writes, I would benchmark the exact production workload before choosing.
Final note
These numbers are not meant to be universal Redis or Valkey performance numbers.
They describe one specific environment:
- three CPU cores
- two I/O threads
- 100 concurrent connections
- 100-byte values
- one million-key dataset
- persistence disabled
- Incus containers
- same host-side benchmark client
Different CPUs, value sizes, connection counts, persistence modes and network setups can change the result.
The main thing I took from the testing is that the workload matters much more than the product name.
For my read-heavy tests, Valkey came out ahead more often. For heavier write traffic, Redis remained very competitive and sometimes faster.