Valkey as a Redis replacement: a real migration with Valkey 8.1

Actualizado: 2026-05-03

Valkey 8.1 shipped on March 31 and is the version that made me take migration seriously. Until now we had been testing it in staging since the March 2024 fork, when Redis changed its license and the Linux Foundation backed Valkey as the libre continuation. Valkey 8.0 in September was already solid, but the multi-threading improvements in 8.1 closed the last gap holding me back. Two weeks ago we migrated the first production cluster. This post covers that migration without promotion or gratuitous criticism.

For the historical context of the Redis license change, the post on Valkey as a Redis fork covers the background of the change that precipitated this scenario.

Key takeaways

• Valkey 8.1 is protocol and command compatible with Redis 7.x; most existing clients work without changes.
• The simplest migration is dump/restore; zero-downtime requires asymmetric replication and is viable but has considerations.
• Real-load performance is comparable to or slightly better than Redis 7.2 on I/O-bound; 8.1’s multi-threading improvements show on CPU-bound.
• Adjustment points we found: module configuration, metric names in exporters, and clients hardcoding version strings.
• Valkey maintains Redis Cluster and Sentinel; no change in the high-availability model.

Why Valkey 8.1 changes the equation

The March 2024 fork was inevitable once Redis changed from BSD to SSPL. The open source ecosystem needed an alternative that could receive contributions without license restrictions. The Linux Foundation backing Valkey gave it institutional credibility, and AWS, Google Cloud, and other cloud providers starting to offer Valkey as a managed cache option accelerated adoption.

What distinguishes 8.1 from earlier versions is the improved I/O threading. Redis was always single-threaded for commands, with multi-threaded I/O since Redis 6. Valkey 8.1 refines that model: granular bucket mutex reduces contention on workloads with many small keys, which is the typical web cache pattern. In our load tests, we saw a p99 latency reduction of around 15% compared to Redis 7.2 on the same hardware, with the same session cache workload.

Compatibility: what works without touching anything

Valkey implements the same RESP2 and RESP3 protocol as Redis. Commands are identical for the core set: strings, hashes, sets, sorted sets, lists, streams, HyperLogLog, pub/sub, Lua scripting, MULTI/EXEC transactions. Configuration in valkey.conf follows the same structure as redis.conf, with the same directives.

Clients we tested without modification:

• redis-py (Python): works fully, including cluster mode and pipeline.
• Jedis and Lettuce (Java): work, including pooling and Sentinel.
• ioredis (Node.js): works, including cluster.
• go-redis (Go): works.

Not a single line of application code needed changing. The switch was at the infrastructure level: changing the container image from redis:7.2 to valkey/valkey:8.1 in docker-compose.

Where we needed to adjust

Although compatibility is high, we found friction in three areas:

Modules. We were using RedisJSON and RediSearch. Valkey doesn’t load Redis modules directly, and Valkey’s equivalents (json and search as its own modules) still have differences in some advanced commands. We decided not to migrate data dependent on modules and kept a separate Redis for that use case, which is a small percentage of total workload.

Exporter metrics. Oliver006’s redis_exporter works with Valkey, but some metric names changed in 8.1. Prometheus alerts referencing specific Redis metrics had to be updated. Not major work, but required going through each alert and verifying the metric name matched. The updated exporter already includes compatibility with the new names.

Clients with version string matching. We had an internal client that parsed INFO server output to determine whether the server was “Redis” and which version. With Valkey, INFO server output returns redis_version: 7.2.x for compatibility, but also adds valkey_version: 8.1.x. Code looking for redis_version kept working, but code looking for the literal string “Redis” in INFO server output failed. An easy bug to fix but easy not to anticipate.

The migration: dump/restore vs. asymmetric replication

For the cluster we migrated, we chose the dump/restore approach with a 15-minute maintenance window. The process:

1. SAVE on Redis to generate the latest RDB.
2. Copy the RDB to the new Valkey server.
3. Start Valkey with the RDB loaded.
4. Verify consistency against a key sample.
5. Change endpoints in application configuration.
6. Restart the application.

For workloads that don’t tolerate downtime, the alternative is asymmetric replication: configure Valkey as a Redis replica, let it sync, then promote to primary and repoint clients. This works because Valkey understands Redis’s replication protocol, but you need to verify version compatibility (Valkey 8.1 can replicate from Redis 7.x but not from older versions without intermediate version jumps).

Production performance: the two following weeks

After two weeks in production, numbers are consistent with staging tests:

• p50 latency practically identical to Redis 7.2 on our cache workload.
• p99 latency around 12-15% better at peak hours, when I/O load is high.
• Slightly more efficient CPU usage in I/O workers.
• No incidents related to the migration.

Memory usage is essentially the same; Valkey has no significant improvements in that area in 8.1 (work is in progress for more efficient data structures in future versions).

My read

Valkey 8.1 is production-ready for the cache use case. Protocol and command compatibility is high enough for most teams to migrate without touching application code. Friction areas are known and manageable: third-party modules, metric exporters, and code making version string assumptions.

The question is no longer “is Valkey mature enough?” but “what’s the incentive to migrate?” If you use Redis under an open source license (Redis Stack or modules under SSPL) and that creates no legal concern, the incentive is lower. If you use Redis OSS 6.x or 7.x and are evaluating an infrastructure refresh, Valkey 8.1 is the most direct alternative that exists today.