DragonflyDB

What it is

DragonflyDB is a Redis-compatible in-memory data store, rewritten from scratch to take advantage of modern hardware. It speaks the Redis RESP2 and RESP3 protocols, so most Redis clients and tools work without code changes, but it is a clean-room reimplementation — not a fork.

The pitch is significantly higher throughput per node. Where Redis is single-threaded for command execution, Dragonfly uses a shared-nothing multi-threaded architecture and asynchronous I/O (io_uring on Linux). On the same hardware, Dragonfly’s benchmarks show roughly 25× the per-node throughput, with lower memory overhead per stored byte.

Founded in 2022 by Roman Gershman and Oded Poncz (both ex-Google). The project’s open-source license is BSL 1.1, which converts to Apache 2 after four years.

Why people use it

• Throughput. A single Dragonfly node handles workloads that previously required a Redis Cluster. This simplifies operations significantly — no shard management, no cross-key command limitations.
• Memory efficiency. Custom data structures (denser hash tables, compressed strings for small values) reduce memory footprint by 30–50% on many workloads.
• Modern architecture. io_uring on Linux, shared-nothing threading, vectorized command processing. Designed for cloud hardware with many cores and fast NVMe storage.
• License clarity. BSL 1.1 with automatic conversion to Apache 2 is more predictable than the Redis SSPL/RSAL/AGPLv3 situation in 2024–2025.
• Drop-in replacement. Most Redis applications work unchanged. The migration path is “swap the connection string.”

When to use DragonflyDB

• High-throughput caching workloads where Redis on a single node is the bottleneck.
• Cases where you’d otherwise need Redis Cluster but want to avoid its operational complexity.
• Modern cloud hardware with many cores — Dragonfly scales with cores; Redis doesn’t.
• New deployments where the Redis license situation is a concern.
• Memory-pressure-sensitive deployments where Dragonfly’s smaller footprint saves real money.

When not to use DragonflyDB

• Small workloads where Redis on a single core is already underutilized.
• Workloads that depend on specific Redis modules with partial Dragonfly parity (RedisJSON and RediSearch features are implemented but not always 1:1).
• Cases where operational maturity outweighs raw performance — Redis has 15+ years of war stories; Dragonfly is newer.
• Organizations that have hard rules against BSL-licensed code.

Notable trade-offs

• Younger codebase. First commit in 2021, 1.0 in 2023. Production deployments exist at scale but the long-tail of edge cases is shorter than Redis’s.
• BSL 1.1 license. Source-available, not OSI-approved as open source. Converts to Apache 2 four years after each release. Some organizations treat BSL carefully even with the conversion clause.
• Feature parity is high but not perfect. Most commands work, but verify the specific Redis features your application depends on — particularly Lua scripts, pub/sub edge cases, and specific module behaviors.
• Tooling ecosystem is thinner. Operational tools (monitoring exporters, admin UIs, training material) are smaller than Redis’s. The gap is closing.

Ecosystem

• Dragonfly Cloud. Commercial managed offering from the same company.
• Self-hosting. Official Docker images, Kubernetes Helm charts. Operates similarly to Redis — same client libraries, similar deployment patterns.
• Memcached compatibility. Dragonfly also speaks the Memcached protocol, making it a drop-in for that use case as well.
• Cluster mode. Dragonfly Cluster (multi-node) exists but most users run single nodes by design.