Valkey vs Redis: Should You Migrate After the Fork?

For over a decade Redis was the default answer to caching, rate limiting, session storage, and job queues. Then in March 2024 Redis Ltd changed the license, and within a week the answer had a second name: Valkey. I run Redis-compatible instances on my own VPS and lean on managed caches at work, so when the fork happened I had to actually decide what to install going forward. This post is the decision I walked through, minus the license-war Twitter noise.

The short version: this is no longer a story about a company betraying its community. Redis reversed course, both projects are open source again, and the two codebases have started to diverge in interesting ways. That makes the comparison more nuanced than a headline can capture, so let us walk it properly.

How we got here: the license timeline

You cannot reason about the trade-off without the sequence of events, because the thing everyone was afraid of in 2024 no longer exists in 2026. Here is the actual chain of decisions.

• Before March 2024: Redis shipped under the permissive BSD 3-Clause license — the same family Valkey now uses.
• March 2024: Redis Ltd moved to a dual source-available model (RSALv2 and SSPLv1). Neither is OSI-approved open source, which triggered the split.
• Days later: former maintainers forked Redis 7.2.4 and, backed by AWS, Google, Oracle, and Ericsson, placed it under the Linux Foundation as Valkey, BSD-licensed.
• May 2025: Redis backpedaled and added AGPLv3 — an OSI-approved open-source license — to Redis 8, alongside its source-available tiers.

So both are open source today. But AGPLv3 is a copyleft license with real obligations if you modify the server and expose it over a network, while Valkey's BSD 3-Clause asks only for attribution. If your legal team has ever flinched at the letters AGPL, that difference alone can decide the question.

What actually changed under the hood

For the first year Valkey was essentially Redis 7.2 with a different logo. That is no longer true. Since forking, Valkey shipped 8.0 and 8.1 with engineering that Redis OSS did not have at the same time, and this is where the projects genuinely diverge.

• Asynchronous I/O threading (8.0): network reads, parsing, and response writes are offloaded to I/O threads while command execution stays single-threaded, pushing throughput past a million requests per second on suitable hardware.
• A redesigned hashtable (8.1) that cuts roughly 20 to 30 bytes of overhead per key, which is real money at scale.
• Iterator prefetching making commands like KEYS and replication sync around 3.5 times faster, plus targeted wins like ZRANK up to 45 percent faster for leaderboards.
• Structured logging (logfmt and ISO 8601) and a COMMANDLOG for tracking oversized requests — small operability touches that add up.

Redis has not stood still either. Redis 8 brought its own command speedups and added Vector Sets for embedding search. The takeaway is not that one is universally faster — it is that they are now two separate products with separate roadmaps that happen to share an ancestor.

Drop-in compatibility: how close is it really?

Because Valkey forked from Redis 7.2.4 and kept the RESP protocol and full command set, your application code does not need to change. The same client libraries connect, the same commands run, RDB and AOF files load. On my own boxes I stopped the Redis container, started a Valkey one pointed at the same data directory, and the app never noticed.

# Same client, same commands — this is the whole point
redis-cli -h cache.internal ping        # PONG
redis-cli -h cache.internal info server | grep -E 'redis_version|server_name'
# On Valkey you'll see something like:
#   server_name:valkey
#   valkey_version:8.1.0
#   redis_version:7.4.0   <- reported for client compatibility

The other compatibility caveat is the proprietary Redis modules — RediSearch, RedisJSON, RedisBloom, and the newer Vector Sets. Those are Redis Ltd features and are not part of Valkey. Valkey has its own module story and community equivalents, but if your stack leans on RediSearch specifically, that is the line that makes migration non-trivial.

Valkey vs Redis at a glance

So should you migrate?

My honest answer is that for a plain cache or session store, the decision is low-stakes in both directions — which is exactly why you should default to the option with fewer legal strings attached. Here is how I actually split it.

• Migrate to Valkey if you self-host, want a permissive BSD license, care about vendor-neutral governance, or want the 8.x memory and threading gains without licensing questions.
• Stay on Redis if you depend on RediSearch, RedisJSON, or Vector Sets, are happy with AGPLv3, or run fully on Redis Cloud and value first-party support.
• Do nothing yet if you are on a managed Redis that just works and have no license, cost, or feature pressure — a migration for its own sake is wasted risk.

How I would run the migration

1. Inventory your usage: dump the command set and check for any proprietary modules with MODULE LIST before assuming a clean swap.
2. Pin and test clients: upgrade your Redis client library to a current version and run your integration suite against a local Valkey container.
3. Replicate, do not dump-and-pray: point a Valkey replica at your Redis primary with REPLICAOF, let it sync, then promote it during a maintenance window.
4. Cut over and watch: flip the connection string, keep the old Redis warm for a fast rollback, and monitor latency and error rates for a full traffic cycle.

# Live migration via replication (zero-dump)
# On the new Valkey instance:
valkey-cli> REPLICAOF redis-primary.internal 6379
valkey-cli> INFO replication        # wait for master_link_status:up

# Once fully synced, promote Valkey to standalone:
valkey-cli> REPLICAOF NO ONE
# ...then repoint your app's connection string and keep Redis warm for rollback.

After doing this on my own infrastructure, the swap for a straight cache was genuinely uneventful — the interesting work was the client-version audit and confirming no proprietary modules were in play, not the data move itself. That is the whole story of a good drop-in: the boring migration is the successful one.