Dragonfly vs Redis vs Valkey: a fair, reproducible benchmark (7-part series)

I benchmarked Dragonfly, Redis, and Valkey on 48 real bare-metal cores — and the honest answer isn't "X wins." It's a trade-off, and the shape of it is more useful than any single number. Same hardware, read-heavy pipelined load, 48 cores:

• 🐉 Dragonfly (one process): 15.5M ops/s
• 🔴 Redis Cluster, driven by a normal client: 4.6M ops/s
• 🔴 Redis Cluster, driven perfectly: 40.6M ops/s

All three are real. Redis's raw ceiling is higher — but you only reach it with flawless client-side routing and a client as big as the server. Dragonfly gives you 3.4× a realistic cluster's throughput for near-zero operational effort. This series puts numbers on that trade-off — and shows exactly how I kept it fair, including a bias I caught in my own setup.

Everything is reproducible: the harness, pinned versions (Redis 8.2.8 · Valkey 8.1.9 · Dragonfly v1.40.1), and the raw runs.csv are public. Rerun it and challenge me. → the repo

The series

1. How I kept it honest — methodology & fairness — the traps that make most in-memory benchmarks lie, and how I disarmed each one. Start here.
2. Throughput & scaling on 48 cores — the full setup, every config and tweak, and the chart where three completely different shapes appear.
3. Why a normal client gets 4.6M out of a cluster that can do 40M — a debugging story that turned into the most interesting finding: how hard it actually is to use a Redis Cluster's throughput.
4. Latency under load — p50/p99/p99.9, and why the naive-cluster tail explodes (honestly read).
5. Memory efficiency — bytes per key; the least-disputable number in the series.
6. Operational simplicity: the cross-key tax — cross-slot, hash-tags, multi-key & Lua — Dragonfly's real structural advantage, quantified.
7. When to use which — the decision table and the three-way trade-off.

Verified against DragonflyDB founder Oded Poncz's benchmarking notes before publishing. Benchmarked on AWS c7i.metal-24xl (48 physical Sapphire Rapids cores) + a c7i.24xlarge client, us-east-1, same placement group.

About the author

I'm Sunny Sahijwani — a senior backend & DevOps engineer.

👉 Connect with me on LinkedIn — I'm always happy to talk in-memory databases, performance, and systems architecture.

The full harness, pinned versions, and raw data for this benchmark are public on GitHub — rerun it and tell me where I'm wrong.