Valkey vs DragonflyDB vs Redis in 2026, and Whether You Need Any of Them
The license fight that started the fork has quietly changed again. Here is where the three engines actually differ, and why a lot of Redis deployments are a cache, a queue, and a channel that Postgres already handles.
Two years after Redis changed its license and the fork happened, the situation people remember is out of date. It is worth restating what is true now before deciding anything, because the license was the entire reason many teams moved.
Everything below was checked against the projects’ own license files and release feeds on 21 August 2026.
Where the licenses actually stand
Redis since version 8 is tri licensed: you may take it under the Redis Source Available License v2, the Server Side Public License v1, or AGPLv3. The AGPL option is an OSI approved open source license, which means the plain claim that Redis is no longer open source stopped being accurate. Current release is 8.10.1.
Valkey is BSD 3-Clause, the license Redis had before all this, and is the Linux Foundation stewarded continuation of that lineage. Current release is 9.1.1.
DragonflyDB is under the Business Source License 1.1, which is source available rather than open source: free for most uses, with a restriction on offering it as a competing managed service, converting to an open license on a schedule.
If your migration off Redis was motivated purely by licensing, the AGPL option may make that migration unnecessary. If it was motivated by wanting BSD terms with no strings, Valkey is the direct answer and always was.
Where they differ once the license stops mattering
Valkey is the conservative choice, and that is a compliment. It is the same codebase your operational knowledge was built on, with the same commands, the same failure modes, and the same client libraries. Migrating from Redis is usually a matter of pointing at a different binary. The project has kept moving on performance and multithreaded I/O rather than reinventing the data model.
DragonflyDB is a rewrite that keeps the protocol. It uses a shared nothing threaded architecture designed to use a large machine properly rather than running one process per core and sharding across them. If your Redis story is “we run twelve instances on one big host because Redis is single threaded,” Dragonfly is aimed directly at that, and consolidation is a real operational win.
Redis itself has not stood still, and the reasons to stay are the boring good ones: it is what your managed provider offers, it is what your monitoring already understands, and the modules you might want are built for it first.
The honest summary is that all three are fast enough that raw throughput is rarely the deciding factor at ordinary scale. The deciding factors are licensing, whether your provider offers it, and how many processes you want to operate.
The question underneath: is this a cache or a database
A large share of Redis deployments do three things: cache computed results, hold a work queue, and carry pub/sub notifications. All three have a Postgres answer now, and if you already run Postgres, adding a second stateful system has a cost that does not show up in a benchmark.
An unlogged table with an expiry column is a serviceable cache when your hit volume is in the thousands per minute rather than the hundreds of thousands per second. It costs nothing new to operate and it participates in your existing backups and access control.
SELECT ... FOR UPDATE SKIP LOCKED is a genuinely good queue primitive, and the reason a generation of job libraries moved onto Postgres. It gives you transactional enqueue, which is the thing Redis cannot give you: the job and the row it refers to commit together or not at all. That property removes an entire class of bug that teams normally discover in production.
LISTEN and NOTIFY cover notification fan out for modest volumes, with the caveat that it is fire and forget and that it does not survive a connection through a transaction pooler. If your Postgres sits behind PgBouncer in transaction mode, this one is off the table entirely, which is a good example of how these decisions interlock.
When Redis or its relatives are clearly right
Rate limiting at request volume, session storage read on every page load, leaderboards and sorted sets, and anything where sub millisecond latency is a product requirement rather than a preference. Those are the workloads where a dedicated in memory store earns its operational cost, and where trying to do it in Postgres shows up as contention on the database that also serves your users.
The pattern that goes wrong is adding Redis early for a workload the database was handling fine, and then discovering two years later that cache invalidation bugs and a second failover story are now part of every incident.
Picking
Already on Redis, no license constraint, everything works: stay. The AGPL option removed the reason most teams were planning to move.
Need BSD terms or want the Linux Foundation governance: Valkey, and the migration is about as easy as infrastructure migrations get.
Running many Redis processes on a few large machines and feeling the operational drag: DragonflyDB, with the Business Source License read carefully if you sell anything database shaped.
Not running any of them yet and wondering whether you should: probably not yet. Write the cache as a table, the queue with SKIP LOCKED, and see which one hurts first. The one that hurts tells you what to add, and by then you will know the access pattern well enough to size it properly.