Redis vs Dragonfly: Architecture, Benchmark Comparison, and Performance Analysis

1 Redis Counterattack

In response to the emergence of Dragonfly, Redis co‑founder and CTO Yiftach Shoolman, together with Redis Labs architects, published an article titled "Does Redis need a new architecture after 13 years?" presenting a Redis 7.0 vs Dragonfly benchmark where Redis showed 18%‑40% higher throughput.

They acknowledge Dragonfly’s novel ideas (e.g., io_uring, modern dictionaries) and note that some of these may be incorporated into Redis in the future, while also arguing that the benchmark methodology does not reflect real‑world Redis usage.

2 Speed Issue

Dragonfly’s benchmark compared a single‑process Redis instance (single core) with a multi‑threaded Dragonfly instance (using all available cores). To make a fairer comparison, the authors tested a Redis 7.0 cluster with 40 shards on AWS c4gn.16xlarge against Dragonfly on the same instance type.

The results showed Redis throughput 18%‑40% higher even when using only 40 of the 64 vCores.

3 Architectural Differences

Background

Developers often base architecture decisions on past pain points. Redis originally chose a multi‑process, no‑shared‑memory design, which scales horizontally via clustering.

Design Principles

Run multiple Redis instances per VM to achieve linear vertical and horizontal scaling, improve replication speed, and enable rapid recovery from VM failures.

Limit each Redis process size (≤25 GB, ≤50 GB with Redis on Flash) to reduce memory overhead during fork, snapshots, and AOF rewrites.

Horizontal scaling is paramount because it provides better elasticity, easier expansion, cost‑effective scaling, higher throughput, and better alignment with NUMA architectures.

Avoid storage throughput limits by adding more nodes rather than relying on external disks.

4 Summary

Redis appreciates community‑driven innovations and may adopt some of Dragonfly’s ideas, but it will continue to uphold its core principles of a shared‑nothing, multi‑process architecture that delivers optimal performance, scalability, and resilience for real‑time in‑memory data platforms.

5 Appendix: Redis 7.0 vs Dragonfly Benchmark Details

Result Overview

Redis version: 7.0.0 built from source.

Dragonfly version: source built from the June 3 commit (hash=e806e6c…).

Test Objectives

Validate reproducibility of Dragonfly’s published results.

Determine the best achievable OSS Redis 7.0 cluster performance on AWS c6gn.16xlarge and compare it with Dragonfly.

Client Configuration

Large number of open connections to the Redis cluster (each memtier_benchmark thread connects to all shards).

Two memtier_benchmark processes on the same client VM gave the best results.

Resource Utilization and Optimization

Redis cluster performed best with 40 primary shards, using 24 spare vCPUs.

Dragonfly fully saturated all 64 vCPUs.

Both solutions were tuned to match Dragonfly’s environment; Redis could potentially improve further with different settings.

Benchmark Commands

Redis:2X: 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

Dragonfly: 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

Similar commands were used for 30‑pipeline GET/SET tests and for single‑GET/SET latency measurements.

Test Facility Details

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

All benchmark data, charts, and detailed analysis are available in the original Redis blog post.