I put off the Valkey migration for about a year because I assumed it would be a whole thing. Config surgery, client library churn, a tense afternoon watching error rates. Then one slow Tuesday I finally did it on a side project, changed one line in a Docker compose file, and everything just kept working. I stared at my dashboard waiting for something to go wrong. Nothing did.
So let me save you the year of dread. If you’re running Redis today and you’ve been vaguely aware of “that fork thing,” here’s what actually happened, why it matters, and how the switch really goes.
What the fork was actually about
In March 2024, Redis Ltd. changed the license on Redis from the permissive BSD-3-Clause to a dual SSPL and RSALv2 arrangement. In plain terms, the code you’d been using under one of the most liberal open source licenses around suddenly came with strings, aimed mostly at cloud providers reselling Redis as a managed service.
The reaction was fast. Within days, a group of contributors from AWS, Google, Oracle, and Ericsson forked the last BSD-licensed version, Redis 7.2.4, and handed it to the Linux Foundation. They called it Valkey. The Linux Foundation’s own writeup tells the origin story, and the short version is that the community wanted a version nobody could quietly relicense again.
That governance point is the part I actually care about. Valkey is BSD-3-Clause under a foundation, which means no single company owns it and no single company can change the deal on you later. Redis, for its part, added an OSI-approved AGPLv3 option in May 2025, so the licensing picture is less hostile than it was at the peak of the drama. But AGPL and BSD are different animals, and for a lot of teams the foundation-governed BSD fork is simply the safer default.
The migration is almost insultingly easy
Here’s the thing nobody quite believed at first: Valkey is wire-protocol compatible with Redis. It forked from Redis 7.2.4, so your existing clients, your commands, your data structures, all of it works without code changes. The redis-cli you already have connects to it. Your application’s Redis library has no idea anything changed.
For most people the entire migration is a container image swap:
# before
services:
cache:
image: redis:7.2
ports:
- "6379:6379"
command: ["redis-server", "--appendonly", "yes"]
# after
services:
cache:
image: valkey/valkey:8
ports:
- "6379:6379"
command: ["valkey-server", "--appendonly", "yes"]
Your app config doesn’t move. A Laravel .env still says REDIS_HOST, a Node app still points its ioredis client at port 6379, and both connect happily. You can even keep calling the binary redis-server in a lot of setups because Valkey ships compatibility shims, though I’d switch to valkey-server so future-you isn’t confused about what’s actually running.
If you’re on a managed service, check your provider’s console. Most of the big ones added a Valkey option, and the switch there is usually a dropdown and a maintenance window rather than a real migration.
What about my existing data?
This was my actual fear, and it turned out to be nothing. Because Valkey forked from Redis 7.2.4, the on-disk formats match. Your dump.rdb snapshot and your append-only file are the same formats Valkey reads. In practice you can stop Redis, point Valkey at the same data directory, and start it back up with your keys intact.
# stop the old server, then start valkey against the same data dir
valkey-server --dir /var/lib/redis --appendonly yes
# your keys are just... there
If you’re running with replication, you can go even smoother: stand up a Valkey instance as a replica of your live Redis primary, let it sync, then promote it and cut traffic over. That gives you a rollback path, which is the thing that actually lets you sleep during a migration. I did the lazy version on my side projects and the careful version on anything with real traffic, and both were undramatic. The careful path just meant I never had a window where the cache was cold.
The one place to slow down is if you lean on Lua scripts or specific INFO fields for monitoring. The scripting engine is compatible, but double-check any dashboards that parse server output, since a few version strings and field names shift. That’s a five-minute audit, not a project.
Is it actually faster, or is that marketing?
This is where I get suspicious, because every fork claims to be faster. But Valkey 8.0 made two changes that are real and measurable rather than benchmark theater. It added native multi-threaded I/O, and it improved memory efficiency in how it encodes data. The official Valkey site documents the throughput work, and the multi-threading in particular helps when you’re network-bound rather than CPU-bound, which describes most cache workloads I’ve run.
I won’t quote a headline number at you, because your mileage depends entirely on your access pattern, your payload sizes, and your hardware. What I’ll say from my own boxes is that I saw a modest but genuine drop in tail latency under load after moving, and zero regressions. Modest and genuine beats dramatic and fake every time.
One honest caveat: if you were paying for Redis Enterprise features like the specialized modules, Valkey’s ecosystem for those is younger. The core key-value engine is a clean swap. The fancier add-ons are where you need to do your homework before assuming parity.
It’s also worth remembering that “faster” only matters if speed was ever your bottleneck. For most apps I’ve run, the cache was never the slow part, the database behind it was. If that’s you, treat the performance numbers as a pleasant bonus rather than the reason to move. The reason to move is the license and the governance. The speed is just a nice thing you get for free on the way.
When I’d still stay on Redis
I’m not here to tell you Redis is dead, because it isn’t. If your shop is deep into Redis Stack modules, or you’re already on Redis Enterprise with a support contract you like, ripping that out to chase a license principle is a poor trade. Tools should earn their place by solving your problem, not by winning an argument on the internet.
But for the common case, an in-memory cache or a queue backend or a rate limiter, Valkey is the boring, safe, free choice now. I’ve moved most of my personal infrastructure over, the same way I moved off proprietary vector stores when the open option got good enough, which I wrote about in my piece on dropping Pinecone for pgvector. The pattern is the same: when a permissively licensed option reaches parity for your use case, the switch usually costs less than the anxiety you built up about it.
What to do this week
Pick your least important Redis instance, the cache in front of some side project nobody will page you about, and swap the image to valkey/valkey:8. Run your normal load against it for a day. Watch your metrics. When nothing breaks, and it won’t, you’ll have the confidence to schedule the real ones.
That’s the whole playbook. One line in a compose file, one day of watching graphs, and you’re off a license you didn’t choose and onto one a foundation maintains. I help teams make exactly these kinds of unglamorous infrastructure calls, and you can find more about that work on my about page. Start small, trust the wire compatibility, and stop dreading the thing that turned out to be a one-line change.
