Valkey vs DragonflyDB vs Redis 2026: Reality Check

Two years ago, Redis quietly stopped being open source and the internet had a small meltdown. Everybody had opinions. Few teams actually moved.

That has changed. Valkey is running ElastiCache, Memorystore, and a long tail of self-hosted clusters at meaningful scale. DragonflyDB shipped cluster mode and crossed enough of the compatibility line that the “but does BullMQ work?” question finally has a real answer. And Redis itself relicensed again — Redis 8 ships under a tri-license that includes AGPLv3, which changed the legal calculation for a lot of SaaS shops in a direction nobody really wanted.

So the “should I leave Redis?” question stopped being theoretical sometime in late 2025. Below is the honest version of where each option is in mid-2026, and which one I’d actually pick for which workload.

What actually shipped on each side

I keep seeing comparison posts that lean on the original 2024 fork moment and don’t reflect what happened since. Quick state-of-play, end of May 2026:

Valkey is on the 8.x line. The headline change from 8.0 was the I/O multiplexing work that finally lets you saturate more than one core for network work without going to a full multi-threaded architecture. 8.1 added per-slot replication improvements and a cleaner pluggable module API. It’s BSD-licensed, governed by the Linux Foundation, and the contributor list is genuinely broad — AWS, Google, Oracle, Ericsson, plus a healthy individual contributor base. Not a vendor-controlled fork in any meaningful sense.

DragonflyDB crossed 1.30 with two things that actually matter: cluster-mode parity with Redis Cluster clients, and a BullMQ compatibility path that doesn’t need glue code. Dragonfly’s whole pitch has always been the multi-threaded shared-nothing architecture, and the 1.30 line is the first time I’d call it a real Redis-replacement candidate for queue and pub-sub workloads, not just pure-cache. The Business Source License is still BSL 1.1 with a four-year clock to Apache 2.0, which is more permissive than AGPL but not OSI-approved.

Redis 8 shipped under RSALv2 + SSPLv1 + AGPLv3 — pick one. Vector sets are the big new feature, and the eight-engine consolidation into one binary (Stack-by-default essentially) is genuinely nice. But the AGPL option is the one that changed the conversation, because it means a lot of legal teams that were fine with SSPL-for-cloud-providers are now staring at “network use is distribution” language and trying to figure out what it means for their SaaS.

KeyDB — I keep getting asked. It’s effectively dormant. Snap acquired it, the public repo has had cosmetic activity, and there’s no roadmap I’d bet a production deployment on. If you’re on KeyDB today, you’re choosing between Valkey and Dragonfly, not whether to stay.

Drop-in reality check

This is the part most posts get wrong, because they answer “is it API-compatible?” instead of “will my app actually work?”

Valkey is genuinely drop-in for Redis 7.x. Same protocol, same commands, same client behavior. node-redis, ioredis, lettuce, go-redis, redis-py — they all just connect. I’ve migrated three production clusters from Redis OSS 7.2 to Valkey 8 by changing the engine on ElastiCache and watching nothing happen, which is the desired outcome. Cluster mode works with the same clients. Sentinel works. The CLI is identical down to the help output.

The asterisk is on Redis modules. RedisJSON, RediSearch, RedisBloom, RedisTimeSeries — those were never part of OSS Redis and they’re not in Valkey. The Valkey community has been building replacements: Valkey-Search exists and roughly tracks RediSearch features, Valkey-JSON is more limited, and the time-series and bloom forks are usable but behind. If you’re a heavy RediSearch user, Valkey gets you part of the way; if you depend on the newer vector and aggregation features, you’re either staying on Redis 8 (and accepting AGPL) or paying Redis Ltd. for Redis Cloud.

Dragonfly is mostly compatible but with sharper edges. Pure GET/SET/HGET/HSET/ZADD-style workloads work without changes. Pipelines work. Lua scripting works for the common cases but has known divergences on edge behaviors — if you have a complex EVAL that depends on Redis’s exact ordering semantics, test it before you cut over. MULTI/EXEC works. Pub/sub works and is honestly faster than Redis. Streams work.

What I would not casually port to Dragonfly: anything that depends on Redis modules (Dragonfly has its own vector/JSON support, but the surface is different), anything with very heavy keyspace notifications that other systems consume, and any code that depends on specific big-key SCAN behavior. Cluster mode in 1.27+ is real but the operational story is younger than Redis Cluster — fewer people have run it through a production failure.

BullMQ on Dragonfly used to be a sore spot. As of 1.30 it works without compatibility hacks, which removes one of the bigger objections.

The architecture difference, and where it actually matters

Valkey is mostly single-threaded with I/O thread offload. Dragonfly is shared-nothing multi-threaded. This is the deepest difference between them, and it’s the one that determines which one wins on your specific workload.

The single-threaded model is genuinely good. It eliminates a whole category of concurrency bugs, keeps latency predictable, and on cache-sized working sets it’s plenty fast. The I/O multiplexing in Valkey 8 lifts the network-side ceiling without breaking that model. For most applications — session store, rate limiter, hot cache, queue — a single Valkey node handles more traffic than your app does, and you scale by sharding when you outgrow it.

Dragonfly’s multi-threaded design pays off when you have enough cores and enough concurrent work to keep them busy. The classic shape where it wins is high-fanout pub/sub, large pipeline batches against a hot keyspace, or any workload where a single Redis process pegs one core while the other 31 sit idle. On those shapes, Dragonfly is dramatically faster on the same hardware.

The shape where it doesn’t win is anything dominated by a single hot key, anything with heavy MULTI/EXEC across many keys, or workloads where you’ve already sharded Redis across many small instances. If you’ve designed around the single-threaded model, Dragonfly’s threading doesn’t give you anything back.

I’d describe the rule of thumb as: if you’d otherwise be running one big Redis box and feeling the ceiling, Dragonfly probably saves you real money. If you’d otherwise be running many small Redis instances behind a cluster, Valkey is the lower-risk choice and the cost delta is smaller than you’d think.

The benchmark question, with honesty

Dragonfly’s marketing has historically led with “25x throughput, 80% lower cost.” Those numbers are real on the workloads they were measured on, and they’re misleading if you assume they generalize.

They generalize on: high-concurrency GET/SET against a non-trivial keyspace on a single beefy node with no cluster routing. That’s a legitimate workload and Dragonfly is genuinely faster there.

They don’t generalize on: cluster mode (slot routing overhead changes the calculus), Lua-heavy work, workloads with a few very hot keys, big-key SCAN, and anything bottlenecked on disk persistence rather than memory. On those, the gap shrinks dramatically or flips.

The fair version of the benchmark conversation in 2026 is: if you run memtier_benchmark with default-ish parameters against a single node, Dragonfly wins on throughput by a lot, Valkey 8 with I/O threads wins on tail latency by a little, and Redis 8 is between them but closer to Valkey. Run the same benchmark against a three-node cluster and the gap closes substantially. Run it against your actual application workload and you really do need to measure, because the ratios depend on key access patterns more than on the engine.

Vendor benchmarks are not lying, but they pick workloads that favor them. Do yours.

Cluster mode and HA

Valkey Cluster is Redis Cluster — same gossip protocol, same slot model, same client behavior. If you’ve operated Redis Cluster, you’ve operated Valkey Cluster. Sentinel works the same way. Failover behavior is identical. The 8.1 per-slot replication improvements actually help resharding and live migration, which is the thing that used to be the most painful Redis Cluster operation.

Dragonfly Cluster is younger. The protocol is compatible enough that Redis Cluster clients work, but the underlying implementation is Dragonfly’s — which means the operational details (how reshards behave under load, what failover looks like, how you debug a stuck slot) are different and there’s less collective experience to lean on. I’d run Dragonfly Cluster in production today, but I’d want a runbook and I’d want to have rehearsed a failover before I needed one.

For HA on a single node, both have replication. Both handle the standard primary/replica failover. Both have persistence — RDB-style snapshots and AOF-style logs.

What managed pricing actually looks like

I’m going to describe shape rather than dollars because the exact numbers move and you should check current pricing pages before committing.

ElastiCache offers Valkey and Redis OSS as separate engines. AWS priced Valkey roughly 20% under Redis OSS engine when they launched it, and that gap has held. If you’re already on ElastiCache, swapping engines is the cheapest “move off Redis” you can make — same operational story, same console, same dashboards, lower bill.

Memorystore for Valkey is GCP’s equivalent. Pricing is competitive with Redis Memorystore, and the engine is real Valkey, not a fork.

Upstash offers Redis-compatible serverless that runs Valkey under the hood now. The per-request pricing model is unique and great for spiky workloads, brutal for chatty ones.

Aiven runs both Redis and Valkey and the pricing is similar to AWS list.

Redis Cloud (Redis Ltd.) is its own thing. You’re paying for the managed service and the modules, which is the main reason to be there if you depend on RediSearch’s newer features or vector search at scale.

DragonflyDB Cloud is the official managed Dragonfly. Pricing is competitive with ElastiCache Redis OSS engine but you should run your actual workload against it before committing, because the cost-per-throughput claims need to be validated on your shape.

The honest version: at 10GB working sets, the price differences barely matter and you should pick on operational fit. At 100GB+ the per-node-class pricing decisions start to add up to real money, and Dragonfly’s “fewer bigger nodes” model can pull ahead if your workload suits it. At 1TB+ you’re having an architecture conversation, not a vendor conversation.

The AGPLv3 question, plainly

This part has caused more legal-team-tickets than the original 2024 license change, and most of the panic is misplaced.

The actual rule for AGPLv3 is: if you modify the AGPL software and let people use the modified version over a network, you have to offer them the source of your modifications. The “network use is distribution” framing is shorthand for that, and it’s narrower than people remember.

For a typical SaaS that runs unmodified Redis 8 behind an API: AGPL does not require you to open-source your app code. Your app talks to Redis over the network. You haven’t modified Redis. You owe nothing.

For a SaaS that patches Redis to add functionality and exposes that functionality to users: you owe the patches. Not your app. Just the Redis modifications.

For a vendor that builds Redis-as-a-service and offers it to other businesses: you’re the case AGPL was written to cover. You owe the modifications you ship in your managed service.

This is fine for most teams. It’s not fine for the legal team that doesn’t want to track which Redis features you depend on or whether a future engineer might patch the binary. That’s why most large-enterprise legal teams I’ve talked to in 2026 are landing on “just use Valkey” — not because Redis 8 actually triggers obligations, but because Valkey removes a question they don’t want to answer.

The Redis Ltd. CLA is also worth noting if you’re contributing upstream. Don’t, unless your employer is fine with the terms.

So what would I actually pick

Decision shapes, end of May 2026:

Pure cache and session store, single node or small cluster. Valkey. Drop-in, cheaper on managed, no surprises. This is the bulk of “I just need Redis” workloads and Valkey is the obvious answer.
BullMQ, queue, or job-runner backend. Valkey is still my default. Dragonfly works as of 1.30 and is faster on raw throughput, but queues benefit from predictable latency more than peak throughput, and the operational story matters when a stuck job blocks production.
High-fanout pub/sub at scale. Dragonfly. This is the cleanest win for the multi-threaded architecture and the gap is real on the same hardware.
One big box, lots of cores, single-process Redis pegging one of them. Dragonfly. Either run it as the new big box, or use the cost savings to right-size. This is also where Dragonfly’s marketing numbers most closely match reality.
RediSearch, RedisJSON, or Redis vector sets user. Redis 8 if you can swallow AGPL or are paying for Redis Cloud, Valkey + Valkey-Search if you can live with rougher edges. Realistically: stay on managed Redis until Valkey modules close the gap further, which I expect through 2026.
Multi-tenant SaaS, want one less compliance question. Valkey. Not because AGPL triggers obligations for you (it probably doesn’t), but because removing the question is worth the migration cost.
On-prem regulated environment. Valkey. BSD license, foundation governance, no vendor approval needed.
KeyDB today. Plan a migration. Valkey is the closest behavioral match.

The two-years-later read is that Valkey turned out to be the safest landing spot for most teams, Dragonfly carved out a real niche for the workloads it’s actually good at, and Redis 8 is technically excellent but legally awkward enough that the people who’d most benefit from its new features are the ones least able to adopt them.

If you’ve been putting off the “what should we do about Redis” conversation, the cheapest version of it now is: turn on Valkey on whatever managed service you’re already using, run a week of your real traffic against it, and see what breaks. For most of you, the answer will be “nothing,” and the bill goes down. That’s a better outcome than most architecture decisions get to claim.