Dragonfly: a Redis and Memcached replacement that scales vertically

What Dragonfly replaces and for whom

Dragonfly targets teams that already run Redis or Memcached and are hitting a CPU ceiling rather than a memory ceiling. Redis is single-threaded for command execution, so a large instance wastes cores. Dragonfly keeps the wire protocol and the command surface of both systems, which the README frames as "no code changes to adopt". That claim is about the API, not about every operational detail: clients keep speaking RESP or the Memcached text protocol, and the server does the work across threads.

The intended user is an infrastructure or backend engineer who owns a cache tier and can change the server process without changing application code. The project is not aimed at someone who needs a general-purpose database with durable storage guarantees first; it is an in-memory store, and the README's own framing is about throughput, hit rates and resource usage for the same workload size.

How the threading model differs from Redis

The repository topics list fibers and multi-threading, and the README's benchmark section is the clearest statement of the design intent. On an m5.large, Dragonfly and Redis are close: SET throughput is 173K versus 159K QPS, and GET is 191K versus 194K. The README explains this by saying the algorithmic layer that allows vertical scaling "does not take a large toll when running single-threaded".

Move to m5.xlarge and the gap opens: SET goes to 279K QPS against Redis's 190K, GET to 305K against 220K. The README's conclusion is that Dragonfly throughput grows with instance size while single-threaded Redis hits a local maximum. On a c6gn.16xlarge the README reports a 25X throughput increase over a single Redis process, crossing 3.8M QPS, and in pipeline mode with --pipeline=30 it reports 10M QPS for SET and 15M QPS for GET.

Those numbers come from the project's own memtier_benchmark runs, not from independent measurement, and the README states the load generator ran on a separate c6gn.16xlarge machine. Treat them as an indication of scaling behavior, not as a guarantee for your instance type.

Installing Dragonfly and running a first workload

The README links to a Quick Start document under docs/quick-start rather than embedding install steps, and the build-from-source guide lives at docs/build-from-source.md. The repository also publishes a container image, referenced by the README's pull-count badges at ghcr.io/dragonflydb/dragonfly. The README does not print a docker run line, so read the Quick Start page for the exact invocation the project recommends.

Once the server is up, any Redis client works. The README's benchmark section gives the workload style the project measures against, and this is the command it shows:

memtier_benchmark --ratio ... -t <threads> -c 30 -n 200000 --distinct-client-seed -d 256 \
   --expiry-range=...

That drives traffic with 30 clients per thread, 200000 requests per client, a fixed random seed and 256-byte values, with the ratio and thread count supplied by the caller. Point it at the running server and memtier_benchmark prints QPS and latency percentiles at the end of the run. For a plain correctness check, connect with redis-cli and issue SET and GET; the README's compatibility claim is that these behave as they do against Redis.

Memory efficiency and snapshotting are the real cost center

The README devotes a section to memory efficiency rather than only to QPS, which is a signal about where the trade-offs live. The test described fills both Dragonfly and Redis with roughly 5GB using debug populate 5000000 key 1024, applies update traffic with memtier, then triggers bgsave. The README presents a figure comparing how each server behaved, but the text does not give the resulting numbers.

That omission matters if you plan a migration. A fork-based snapshot in a single-threaded server and a snapshot in a multi-threaded server with fibers have different copy-on-write behavior, and the README does not quantify the difference in prose. Anyone sizing a Dragonfly instance should reproduce the populate and bgsave sequence on their own key distribution before trusting a memory estimate carried over from Redis.

Where Dragonfly is the wrong choice

The README does not document rollback, and it does not describe replication topology, failover behavior or persistence guarantees in the excerpt available. If your deployment depends on Redis Sentinel, Cluster slot routing, or a documented point-in-time recovery procedure, this page gives you nothing to verify against, and that absence is itself the answer: keep Redis until you have read the project's docs on those topics.

The Memcached comparison is also more nuanced than the headline. Dragonfly wins on throughput in both directions, 3844K versus 806K QPS for SET and 3717K versus 2100K for GET, but Memcached shows lower read latency, 0.34ms at P99 versus Dragonfly's 1ms. If your workload is read-heavy and latency-sensitive rather than throughput-bound, the throughput advantage does not address your constraint.

Finally, the compatibility claim is about the API surface, not about ecosystem extensions. The README says nothing about Redis modules or scripting semantics, so a workload that relies on either should be treated as unverified.

How it compares with KeyDB and Valkey

The repository topics include keydb and valkey, which places Dragonfly in a field of Redis-derived or Redis-compatible servers. Valkey is a fork of Redis maintained under a different governance model; the practical difference is that Valkey inherits Redis's execution model and its existing operational tooling, so migration from Redis is a version change rather than an architecture change. KeyDB takes the multi-threaded route, closer to Dragonfly's approach, but the README does not describe KeyDB's internals, so no detailed comparison is possible from this page alone.

The honest distinction is scope. Dragonfly is a rewrite in C++ with its own threading and fiber machinery, which is why the README can report scaling with instance size. That same rewrite means the codebase, the build system (CMake plus a helio submodule) and the failure modes are the project's own, not Redis's. Choosing it means choosing to operate software whose internals differ from the system your runbooks were written for.

Maintenance cadence, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-10, so it is under current development. Releases are frequent: v1.40.0 on 2026-08-04, v1.40.1 on 2026-08-06 and v1.40.2 on 2026-09-03. That cadence means patch upgrades arrive often, and pinning a version rather than tracking latest is the safer default for a cache tier.

Licensing needs your own reading. The repository carries a LICENSE.md and a CLA.txt, and the metadata license field is NOASSERTION, meaning no standard identifier was detected. The README does not state licensing terms in the excerpt available, so check LICENSE.md directly and have counsel review it if you redistribute or offer the software as a service. Nothing here should be read as legal advice.

Upgrade cost is mostly operational. The build path uses CMake with a helio submodule and a Makefile that defaults to a release build directory named build-release; building from source is a heavier operation than pulling the container image. For most teams the image is the upgrade path, and the question is whether a restart of the cache tier is acceptable in your deployment.

Editorial conclusion

Adopt Dragonfly if you run a single-threaded Redis or Memcached instance that is CPU-bound and you want to keep the same client libraries and commands. Do not adopt it if your workload depends on modules, Lua semantics or replication topologies the README does not describe, or if you need a documented rollback path. Before switching, verify three things on your own data: which commands your application actually calls, how much memory the dataset occupies under Dragonfly's snapshotting, and whether your client library's connection behavior survives a restart of the server.

Frequently asked questions

Official sources

1. dragonflydb/dragonfly on GitHub
2. Issues
3. Project website
4. README
5. Releases