Valkey vs Redis: The Licence, the Fork, and How to Choose in 2026

The short answer

Valkey is a BSD-licensed fork of Redis 7.2, hosted by the Linux Foundation, created in March 2024 after Redis Ltd. moved Redis off its permissive BSD licence. Redis remains available under a source-available licence and, since Redis 8, also under AGPLv3 — an OSI-approved open source licence.

If the reason you are asking is licensing, the picture has changed and most comparisons you will find are out of date. Redis 8 is open source again by the OSI's definition, provided AGPLv3 works for you. If AGPLv3 does not work for you — and for a great many commercial products it does not — then Valkey's BSD licence is the reason to move, and it is a good one.

If the reason you are asking is anything else, the honest answer is that both are excellent, both are actively maintained, and the decision is about governance and licence posture rather than about which one is faster this quarter.

What actually happened, in order

The sequence matters because most write-ups compress it into "Redis went closed source", which is not accurate and leads teams to the wrong conclusion.

• Up to and including Redis 7.2 — Redis was BSD-3-Clause. Permissive, OSI-approved, usable in essentially any context.
• 21 March 2024 — Redis Ltd. announced that future Redis releases would be dual-licensed under RSALv2 (Redis Source Available License v2) and SSPLv1 (Server Side Public License v1). Neither is OSI-approved. The stated target was managed service providers reselling Redis without contributing back.
• 29 March 2024 — eight days later, a group of six active contributors launched Valkey as a Linux Foundation project, forked from the Redis 7.2 line and continuing under BSD. The first release was Valkey 7.2.5.
• Redis 7.4 through 7.8 — shipped under RSALv2 or SSPLv1.
• Redis 8.0 onward — Redis added AGPLv3 as a third option, making it a tri-licence: RSALv2, SSPLv1, or AGPLv3. AGPLv3 is OSI-approved. This restored an open source option to Redis for the first time since the March 2024 change.

So the common framing — "Redis went proprietary, Valkey is the open one" — was true for about a year and is now too simple. Both have an OSI-approved option. They are different OSI-approved options, and that difference is the whole decision.

The licence decision, stated plainly

This is the part that determines the answer for most organisations, and it takes about five minutes to resolve once the question is put correctly.

The fourth row is the one that catches people. A large share of enterprises operate a blanket AGPL ban in their open source policy, written years before this situation existed and aimed at a different problem. For those organisations, Redis 8's AGPLv3 option is not available in practice, which leaves them on a source-available licence. That is the single most common legitimate reason to move to Valkey, and it has nothing to do with the technology.

Where they have actually diverged

For the first year the two codebases were close enough that the comparison was academic. That is no longer true. Both have shipped multiple major versions since the fork and have made independent architectural choices.

The important thing to understand is that this is now a real fork with real divergence, not a rebadge. Valkey has gone through 7.2, 8.0, 8.1 and into the 9.x line; Redis has gone through 7.4 and into the 8.x line. Feature sets, performance characteristics and internal implementations have moved apart. Benchmarks published in 2024 comparing "Valkey vs Redis" are describing two versions of the same code and tell you nothing useful about the current releases.

What has not diverged, and is the reason migration is usually straightforward, is the wire protocol and the core data model. RESP is the same. The command set for everything most applications use — strings, hashes, lists, sets, sorted sets, streams, pub/sub — is compatible. Client libraries generally work against both without modification.

Support lifecycles

Both projects now publish real lifecycle dates, which is more than can be said for most infrastructure software, and those dates are worth putting in front of whoever owns the upgrade budget.

Note Redis 8.0's date. If you moved to Redis 8.0 to pick up the AGPLv3 option, that branch stops receiving fixes in December 2026 and you are on a two-year upgrade cadence, not a five-year one. Plan accordingly rather than discovering it during an audit.

The migration, and why it is usually easier than expected

Valkey was forked from Redis 7.2 and retains protocol and command compatibility for the operations the overwhelming majority of applications perform. In practice this means:

• Client libraries — existing Redis clients connect to Valkey without changes. There are Valkey-branded clients, and they are good, but switching to them is optional and not part of the migration.
• Data — RDB and AOF files from Redis 7.2 are readable by Valkey. For a replica-based cutover, Valkey can replicate from a Redis primary, which is the mechanism that makes a near-zero-downtime migration possible.
• Configuration — redis.conf directives are broadly recognised. Differences exist and grow with each release, so this is the file to diff rather than assume.
• Operational tooling — anything speaking RESP works. Monitoring that scrapes INFO works, though field-level differences are appearing as the projects diverge.

The realistic sequence for a production estate is: stand up Valkey as a replica of the existing Redis primary, let it sync, verify key counts and a sample of values, then promote during a maintenance window and repoint clients. The risky part is never the data — it is the long tail of applications with a hard-coded host, a forgotten cron job, or a library pinned to a version nobody can rebuild.

Where migration genuinely gets harder is if you are using Redis Stack modules — RediSearch, RedisJSON, RedisTimeSeries, RedisBloom. Those are Redis Ltd. products under the same tri-licence from Redis 8. Valkey has its own module ecosystem, and the equivalents are not drop-in. If your application depends on RediSearch query syntax, that is a rewrite, not a migration, and it should be scoped as one.

The question nobody asks until it is urgent: who patches the version you are on?

Both projects patch their current release lines. Neither patches the line you are probably running.

This is the part of the Redis-versus-Valkey decision that gets skipped, because it is not a comparison question — it applies identically to both. A very large number of production estates are on Redis 6.2 or 7.0. Those are BSD-licensed, entirely legitimate to run, and receive no security fixes from anyone. The licence debate is irrelevant to them; they have a patching problem that predates it.

Redis is written in C. The recurring vulnerability classes are memory-safety issues in command processing — buffer and integer handling in the data-type implementations — reachable by any client permitted to issue the relevant command, plus the surface added by Lua scripting and module loading. These are not theoretical, and they do not stop being disclosed because your branch stopped being maintained.

So the decision tree has three branches, not two:

• Move to Valkey if the licence matters to you, if you want BSD and foundation governance, and if you can absorb a version migration now.
• Move to current Redis if AGPLv3 is acceptable to your legal team and you prefer to stay with Redis Ltd.'s roadmap and the Stack modules.
• Get the version you are on patched if neither migration is happening this year — which, for most estates with a frozen change window or a compliance deadline, is the actual situation. OSSeva backports security fixes to Redis 6.2.x and 7.0.x so the branch you run stays secure while the migration is planned properly rather than executed under audit pressure.

What we would tell you if you asked us directly

For most enterprises: the licence is the deciding factor, and if you have an AGPL prohibition, Valkey is your answer. Migration from Redis 7.2 or earlier is genuinely low-risk if you use replica-based cutover and you have inventoried your module usage first.

For teams using Redis Stack modules heavily: staying on Redis is usually cheaper than rebuilding the search layer, and AGPLv3 may well be acceptable once someone actually reads it rather than applying a policy written in 2015.

For anyone on Redis 6.x or 7.0: the licence argument is a distraction from a live security exposure. Fix the patching first, then decide the destination with time to do it properly.

And for anyone being told this is urgent by a vendor: it is not. Both projects are healthy, both are maintained, and a decision made carefully in Q1 is worth more than one made quickly in Q4.