Valkey 8.1 shipped on March 31 and is the version that made me take migration seriously. Until now we’d been testing it in staging since the fork split in March 2024, when Redis changed its license and the Linux Foundation sheltered Valkey as the free continuation. Valkey 8.0 in September was already solid, but the multi-threading performance improvements in 8.1 closed the last gap that held me back. Two weeks ago we migrated our first production cluster. This post tells that migration without promotion or gratuitous critique, with real data and the surprises I found.
Context: a Redis 7.2 cluster with four nodes (one master, three replicas) behind a fleet of WordPress multisite and several Celery consumers in Python. Average load 9000 ops per second, peaks of 22000, and a key set around 4 GB in memory. Not a huge cluster, but real enough for details to matter.
The migration itself: binary-compatible and fast
First surprise is how little changes at the operations layer. Valkey preserves the RESP protocol, AOF format, RDB format, and the usual commands. A client talking to Redis 7.2 talks to Valkey 8.1 without modification. We literally changed the container image from redis:7.2-bookworm to valkey/valkey:8.1-bookworm and the service came up reading the same AOF.
The only adjustment needed on first boot was the binary name in the compose healthcheck: valkey-cli ping instead of redis-cli ping. And that because I wanted to be explicit; redis-cli still exists as an alias in the image, for compatibility. This deliberate compatibility is a conscious decision by the Valkey team to not force the switch on anyone.
The full cluster migration took about 14 minutes: replica by replica, read-only nodes first, then promotion and master replacement. No service loss or data loss. A boring operation, as it should be.
Performance: what changes and what doesn’t
The key point of Valkey 8 is async I/O multi-threading, a deep improvement not in Redis 7.2. In our cluster the difference shows in two places.
On pure reads under high load, p99 latency drops from 3.2 ms to 1.8 ms. Doesn’t seem like much in absolute terms, but when WordPress does between 20 and 40 lookups per request, it accumulates. The median page render time under peaks (which depends heavily on cache) fell about 80 ms.
On writes with AOF in everysec mode, Valkey 8.1 introduces fsync improvements that reduce variability under high pressure. The occasional 15-20 ms peaks we saw under simultaneous fsync disappeared. Latency is flatter, though the median is very similar.
Memory consumption for the same dataset is marginally lower, between 4 and 5 percent. Not dramatic, but accumulated across a large fleet represents real savings on the infrastructure bill.
What doesn’t change: basic commands (GET, SET, INCR, HSET, LPUSH) have equivalent latency. If your load is almost exclusively simple operations, Valkey 8.1 and Redis 7.2 perform practically identically. The advantage appears when there’s high concurrency and variety of operations.
Replication and cluster mode
This is where I paid most attention before migrating. Valkey’s replication uses the same PSYNC2 protocol as Redis, so it can operate in hybrid mode: a cluster with a Valkey 8.1 replica of a Redis 7.2 master works fine. This is key for progressive migration.
We leveraged that: we migrated the three replicas first to Valkey while the master stayed in Redis, observed for 48 hours that all was well, and only then did a failover to promote a Valkey replica to master. The old master (still in Redis) rejoined as replica and a few minutes later we replaced it. The process is invisible to clients.
Cluster mode works identically, with the same valkey-cli --cluster (or redis-cli --cluster) tool for administrative operations. Nothing to relearn.
Small surprises I found
Three points where migration was more delicate than I expected.
First, some client libraries in niche languages doing probes with inspection commands (INFO replication in specific format) had to be adjusted because Valkey returns some fields in different order or with additional names. Our main clients (phpredis, redis-py, ioredis) had no problem. But a custom monitoring script in Ruby did.
Second, Redis modules without a free equivalent (RedisJSON, RediSearch, RedisTimeSeries) don’t load in Valkey. That’s expected: they’re proprietary modules. For RedisJSON the community equivalent is ValkeyJSON, for search there are solutions in development but nothing mature yet. We didn’t use proprietary modules, so no impact, but that’s the trap where most teams get stuck.
Third, observability tooling. Public Grafana dashboards for Redis work with Valkey unchanged because they use the same INFO metrics. But some fields from Redis Stack or Redis Enterprise simply don’t exist in Valkey. Reviewing panels and accepting that some metrics show “no data” is part of the work.
When migration pays off
If you pay for Redis Enterprise and use modules like RedisJSON or RediSearch, Valkey right now isn’t a direct replacement. You’ll have to wait for the community ecosystem to mature or stay on the commercial version.
If you use Redis open source up to 7.2 with standard commands (SET, GET, HSET, LPUSH, ZADD, STREAMS) and little more, Valkey 8.1 is a literal replacement and, moreover, better under high load. Migration is fast, the protocol is compatible, clients don’t change, and admin tools are the same.
If you’re starting a new project in 2025, the choice is clear: Valkey. It has a real BSD license, a public roadmap, contributions from Amazon, Google, Ericsson and Alibaba. The risk of unilateral license change, which is what caused the fork to be born, doesn’t exist by design: governance is at the Linux Foundation.
If you use Redis 7.4 or later under SSPLv1 and RSAL license, your situation is different. You can stay on Redis if your use doesn’t conflict with the license, or migrate to Valkey to avoid that legal risk. Many companies have done the latter by internal policy, not for technical reasons.
My read
Valkey 8.1 closes the technical doubt some had about the initial fork. It’s no longer a maintained copy of Redis 7.2, but a project advancing on its own with tangible improvements like multi-threading or fsync optimizations. In performance it’s better for concurrent loads, in operation it’s equivalent, and in licensing it’s cleaner for commercial use.
The interesting part is cultural. Migration to Valkey is the first case of a post-license-change fork of a critical project that has actually worked. Elasticsearch versus OpenSearch spent years in confused divergence. MariaDB versus MySQL stayed almost identical until they stopped being. Valkey shows that with foundation governance, hyperscaler contributions, and an organized community, a fork can surpass the original in months, not years.
For teams with Redis in production, my recommendation is concrete: try Valkey 8.1 in staging during the first calm week you find. The cost is low, migration is reversible, and the upside (better performance under load, certain license) is enough to justify it. Those who depend on proprietary modules, wait six more months for the ecosystem to mature. Those who don’t, migrate now and gain peace of mind.
