For fifteen years, "which in-memory store should we use" had a one-word answer. Then March 2024 happened: Redis dropped its BSD license for a source-available dual license, the Linux Foundation forked the last BSD release as Valkey within two weeks, and Dragonfly — a from-scratch, multi-threaded rethink of the same API — kept picking up teams whose Redis instances had outgrown a single core.
In 2026 all three are mature, all three speak the same wire protocol, and your application code will almost certainly run unmodified on any of them. Which is exactly why the choice deserves ten minutes of thought: the differences are no longer in the API, but in licensing, threading, memory behavior and operational character. We run all three as managed services at DanubeData, so we get to see how they behave side by side under real customer workloads. Here is the honest comparison.
The thirty-second history
- March 2024 — Redis 7.4 moves from BSD-3 to a dual RSALv2 / SSPLv1 license. Cloud providers can no longer offer it as a service without a commercial agreement.
- March 2024 — The Linux Foundation announces Valkey, a fork of Redis 7.2.4 under the original BSD-3 license, backed by AWS, Google Cloud, Oracle and others. Most Linux distributions switch their packages to it.
- May 2025 — Redis 8 adds AGPLv3 as a third license option, making Redis open source again by OSI's definition — with AGPL obligations attached.
- Meanwhile — Dragonfly, first released in 2022 under BSL 1.1, keeps building out its multi-threaded implementation of the Redis and Memcached APIs, aimed at replacing whole Redis clusters with one vertically-scaled instance.
If you want the deeper background on either challenger, we have standalone explainers: what Valkey is and what Dragonfly is. This post is about choosing.
Architecture: one core, helped core, or all the cores
Redis: single-threaded command execution
Redis executes commands on a single thread, with I/O threads offloading network reads and writes. This is a feature as much as a limitation — no locks, strictly ordered commands, predictable atomicity — and for the vast majority of workloads a single modern core pushing hundreds of thousands of operations per second is nowhere near the bottleneck. When it is, Redis answer is horizontal: Redis Cluster, with keys sharded across nodes and the client doing the routing.
Valkey: the same model, aggressively optimized
Valkey kept the single-threaded execution model and API but rebuilt the I/O threading around it. Valkey 8 delivered a large multi-core throughput jump on the same hardware compared to the 7.2 code it forked from, plus per-key memory savings from dictionary restructuring. Think of it as Redis 7.2's architecture with the performance ceiling raised and the BSD license kept.
Dragonfly: shared-nothing across every core
Dragonfly is a different animal: a from-scratch C++ implementation where the keyspace is partitioned across threads, each core owning its slice. One instance saturates a big machine — the project's benchmarks claim multi-million ops/sec on a single node — so the pitch is vertical: replace a sharded Redis Cluster and its client-side routing complexity with one process on one large box. Snapshotting is also fork-less, which removes the classic Redis pain of memory doubling during BGSAVE on a write-heavy instance.
Compatibility: will my code just work?
Almost always yes, with asterisks that matter:
- Valkey is a drop-in for the Redis 7.2 API — same commands, same RDB/AOF formats at the fork point, same replication protocol generation. Existing clients, libraries and even most tooling work unchanged. What you do not get: the Redis Stack module features (search, JSON, time series) that Redis has been folding into Redis 8 core — Valkey covers some of this ground with its own modules, but check your specific dependency.
- Dragonfly implements the RESP protocol and the large majority of commonly used commands, including Lua scripting, pub/sub, streams and transactions. Coverage is not 100% of Redis' surface — exotic commands, module-dependent features and some cluster-mode semantics differ (Dragonfly ships an emulated cluster mode so cluster-aware clients can connect to a single node). Run your test suite against it before committing; most apps pass untouched.
- Redis is, tautologically, the compatibility baseline — and the only one of the three where the newer capabilities (the query engine, JSON, vector search in core) are first-party.
The comparison table
| Redis 8 | Valkey 8 | Dragonfly | |
|---|---|---|---|
| License | AGPLv3 / RSALv2 / SSPLv1 | BSD-3 (Linux Foundation) | BSL 1.1 (source-available) |
| Execution model | Single-threaded + I/O threads | Single-threaded + enhanced I/O threading | Multi-threaded, shared-nothing |
| Scale strategy | Horizontal (Redis Cluster) | Horizontal (cluster) | Vertical (one big node) |
| Redis API compatibility | Baseline | Full at 7.2 level | High, not total — test |
| Snapshot behavior | Fork-based (memory spike) | Fork-based (memory spike) | Fork-less, stable memory |
| Search / JSON / vectors in core | Yes (Redis 8) | Via separate modules, partial | Partial (JSON, search subset) |
| Ecosystem maturity | Deepest | Inherited + growing fast | Younger, well-funded |
How to actually choose
Default to Valkey for new caches and queues
For the classic workloads — cache, session store, rate limiting (see our rate-limiting guide), lightweight queues — Valkey is the least-drama choice in 2026: the API everyone knows, a genuinely open license nobody's legal team needs to read twice, active development with real performance wins, and packages in every distro. This is what we suggest by default for new instances on our platform.
Pick Redis when you need what only Redis has
If your roadmap includes the query engine, JSON documents, or vector search served from the same process as your cache — and the AGPL (or a commercial license) is acceptable in your context — Redis 8 is the one first-party home for all of it. Existing Redis deployments that use Stack features have no clean equivalent elsewhere; migrating those to Valkey means re-architecting, not just repointing.
Pick Dragonfly when one box should do the work of a cluster
If a single Redis instance is CPU-bound and the alternative is standing up a sharded cluster — or you already resent the BGSAVE memory spike on a write-heavy 30 GB instance — Dragonfly's vertical model is compelling: fewer moving parts than a cluster, honest multi-core utilization, calm snapshots. The trade: a source-available license and a smaller operational track record than the twin lineage it competes with. It shines for big caches, heavy pub/sub fan-out and throughput-bound workloads.
Migration reality check
Redis → Valkey is trivially easy (replication-compatible at the fork generation; you can literally replicate across and fail over). Redis/Valkey → Dragonfly is usually easy — point your client at it, run the suite, watch for the rare unsupported command. Moving off Stack-module features is the only genuinely hard migration in this family, which is worth remembering before you adopt them casually.
Running them managed, in the EU
We offer all three as managed instances at DanubeData — Redis, Valkey and Dragonfly — hosted in Germany under EU jurisdiction, with the same operational envelope regardless of engine: read replicas, automatic and on-demand snapshots, TLS, private networking to your other DanubeData services, and custom parameter groups when you need to tune. Pricing is on the pricing page; all three engines cost the same for the same resources, so the choice stays technical rather than budgetary.
That neutrality is deliberate. The engines are converging on the same job with different philosophies, and the right answer genuinely depends on your workload — which is a healthier place for this ecosystem than the one-word answer ever was.
Related reading: managed vs self-hosted Redis, caching strategies that actually work, and European alternatives to Upstash.
Spin up a managed cache in Falkenstein and A/B your own workload against all three engines this afternoon.
