Is Dragonfly Really Faster Than Redis? A Deep Dive into Benchmarks and Architecture

In mid‑2023 a former Google and Amazon engineer released Dragonfly, an open‑source in‑memory data cache written in C/C++ and licensed under the Business Source License.

Benchmarks claim Dragonfly is the fastest memory store, supporting Memcached and Redis protocols, offering up to 25× performance over Redis in typical workloads and using 30% less memory for a 5 GB dataset.

Within two months Dragonfly earned 9.2 K GitHub stars and 177 forks, sparking a debate with the Redis team.

Redis co‑founder Yiftach Shoolman, CTO, together with Redis Labs architects published “Do we need a new architecture after 13 years?” comparing Redis 7.0 and Dragonfly. Their tests show Redis throughput 18‑40 % higher than Dragonfly when using a 40‑shard Redis cluster on comparable AWS c4gn.16xlarge hardware.

Redis acknowledges some ideas from Dragonfly (io_uring, modern dictionaries, thread usage) may be incorporated in future releases, but argues the Redis architecture remains the best for real‑time in‑memory data storage.

Benchmark methodology

Redis’s comparison uses a 40‑shard Redis 7.0 cluster (utilising most cores) versus the largest Dragonfly instance (AWS c4gn.16xlarge). Tests cover single‑GET, 30‑GET, single‑SET and 30‑SET pipelines, reporting operations per second and latency.

Key results

Single‑GET: Redis 4.43 M ops/s (0.383 ms avg latency) vs Dragonfly 3.80 M ops/s (0.390 ms).

30‑GET: Redis 22.9 M ops/s (2.239 ms) vs Dragonfly 15.9 M ops/s (3.99 ms), Redis 43‑52 % faster.

Single‑SET: Redis 4.74 M ops/s (0.391 ms) vs Dragonfly 4.00 M ops/s (0.500 ms), Redis 19 % faster.

30‑SET: Redis 19.85 M ops/s (2.879 ms) vs Dragonfly 14.00 M ops/s (4.203 ms), Redis 42‑99 % faster.

Both systems fully utilized the network; TCP could deliver >10 M packets/s and >30 Gbps between client and server VMs.

Redis architecture principles

Redis relies on multiple processes (clusters) for horizontal scaling, keeping each instance under 25 GB (50 GB with Redis on Flash) to simplify replication, snapshotting and AOF rewriting, and to enable fast rebalancing and failover.

Running multiple instances per VM improves linear scaling, replication speed, and fault recovery, while preserving the multi‑process, no‑shared‑memory design that offers the best performance, elasticity and suitability for real‑time workloads.

Test environment

VM type: AWS c6gn.16xlarge (Arm Neoverse‑N1, 64 vCPU, 126 GB RAM).

OS: Arm64 kernel 5.10.

Client and server used identical hardware.

Command lines used for the benchmarks (examples):

memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram

memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

In summary, while Dragonfly introduces interesting multithreaded techniques, Redis’s multi‑process architecture still delivers higher throughput and lower latency under comparable conditions, and its design continues to be well‑suited for real‑time in‑memory data platforms.