Posts Caches
Redis vs Valkey vs Dragonfly
In-memory SET/GET throughput, pipelining, and memory efficiency — Redis 8 vs Valkey 9 vs Dragonfly 1.40 on dedicated ARM hardware.
Small value throughput
SET/GET mix (1:10 ratio) with 100-byte values, pipeline depth 1. RESP2, no TLS.
Dragonfly 1.20M ops/s (p99 0.33 ms); Redis 174K (2.09 ms); Valkey 173K (2.10 ms)
Large value throughput
SET/GET mix (1:10 ratio) with 10 KB values, pipeline depth 1. RESP2, no TLS.
Dragonfly 199K ops/s (p99 1.40 ms); Redis 105K (3.52 ms); Valkey 104K (3.55 ms)
Pipeline effect
SET/GET mix (1:10 ratio) with 100-byte values, comparing pipeline depth 1 vs 30. Candidate statistic: pipeline-30 throughput.
Test 1 Pipeline depth 1
SET/GET mix at pipeline depth 1 (reuses small-value throughput data) (HIGHER ops/s = BETTER)
Redis| Redis | 174,330.2 ops/s |
|---|---|
| Valkey | 173,395.0 ops/s |
| Dragonfly | 1,196,729.8 ops/s |
Test 2 Pipeline depth 30
SET/GET mix at pipeline depth 30 (HIGHER ops/s = BETTER)
Redis| Redis | 1,451,611.2 ops/s |
|---|---|
| Valkey | 1,344,832.6 ops/s |
| Dragonfly | 12,833,173.6 ops/s |
Dragonfly 12.8M ops/s at pipeline 30; Redis 1.45M; Valkey 1.34M
Memory efficiency
Baseline-corrected memory after loading keys with 100-byte values. RSS delta is the primary metric (allocator-neutral).
Dragonfly 112.8 MB RSS delta (118 B/key); Redis 158 MB (166 B/key); Valkey 163 MB (171 B/key)
Test conditions: rig, corpus, protocol
- Machine
- AWS c7g.metal (engine) + c7g.4xlarge (client)
- Chip
- AWS Graviton3
- Cores
- 64 physical (engine)
- Memory
- 128 GiB (engine), 32 GiB (client)
- OS
- Ubuntu 24.04 LTS arm64 (arm64)
- Runtime
- Docker (redis:8.8.2, valkey/valkey:9.1.1, dragonflydb/dragonfly:v1.40.1); memtier_benchmark 2.5.1; RESP2, no TLS
- Warmups
- 2 unmeasured passes
- Measured
- 10 passes per tool
- Process
- Container per engine, network_mode host; Dragonfly 64 proactor threads on 64 physical cores, Redis and Valkey single-threaded I/O (default io-threads 1); 16 GiB maxmemory for all three
- Cache
- Preloaded keyspace, 100% hit ratio on GET workloads; working sets sized below 50% of maxmemory; eviction flags set for parity of intent, never triggered
- Output
- memtier_benchmark 2.5.1: ops/s, p50/p99/p99.9 latency, client CPU per 10 s pass; memory via INFO MEMORY and cgroup RSS delta
What did we learn?
Dragonfly led every section; Redis and Valkey tracked within a few percent of each other.
| Candidate | Small value throughput (ms, lower is better) | Large value throughput (ms, lower is better) | Pipeline effect (ops/s, higher is better) | Memory efficiency (MB, lower is better) |
|---|---|---|---|---|
| Redis | 2.1 ms | 3.5 ms | 1,454,560.3 ops/s | 158 MB |
| Valkey | 2.1 ms | 3.6 ms | 1,344,402.9 ops/s | 163 MB |
| Dragonfly | 0.3 ms | 1.4 ms | 12,794,200.7 ops/s | 112.8 MB |
Dragonfly 1.40.1 (64 threads) reached 1.20M ops/s on small-value SET/GET — 6.9x Redis's 174K ops/s, at 0.33 ms p99 vs 2.09 ms. Pipeline depth 30 widened the gap to 8.8x (12.8M vs 1.45M ops/s). Large values closed to 1.9x, likely network-limited. Dragonfly also used 29% less RSS per key. Redis 8.8.2 and Valkey 9.1.1 tracked within 1% of each other on SET/GET workloads and within 8% on pipelining.
What this does not prove
- Dragonfly's small-value and pipeline cells ran the client at 75–79% CPU — the load generator was near its ceiling, so those Dragonfly numbers are a floor, not a measurement of its limit. Redis and Valkey cells ran the client at 9–16%.
- The 10 KB cell moves ~2 GB/s at Dragonfly's rate, near the client instance's network ceiling — the 1.9x gap there is likely network-bound, not an engine limit.
- Redis and Valkey ran their default single-threaded I/O (io-threads 1); enabling Valkey's/Redis's I/O threads is a different benchmark and is queued.
- Dragonfly ran 64 proactor threads on 64 physical cores; 16 GiB maxmemory for all three; eviction flags set for parity of intent and never triggered (working sets ≤ 50% of maxmemory).
- Persistence off for all three.
- One host each for engine and client, same cluster placement group, RESP2, no TLS; closed-loop latency at 196 connections is measured at each engine's own saturation point.
- KeyDB omitted as effectively unmaintained.
- Memory is baseline-corrected RSS delta after loading 1,000,000 keys with 100-byte values; Dragonfly's per-shard tables scale with thread count, so its fixed cost differs at other thread counts.
Rerun it yourself: the runner and configuration are in the repository, and the methodology page covers what every run holds constant. Think a result is wrong? Open an issue with your rig and your samples.
Redis is a registered trademark of Redis Ltd. Valkey is a trademark of The Linux Foundation. Dragonfly is a trademark of DragonflyDB Ltd.