Redis vs Valkey on Kubernetes: choosing and migrating

An application may use Redis to keep frequently read data in memory, store sessions or manage other shared state. Before replacing that server, find out what would happen if its contents disappeared. A cache that can be rebuilt from a database needs a different migration plan from the only copy of important application data.

Redis and Valkey are in-memory data stores that can serve several of these jobs. Valkey is a separate project with its own releases and a project-maintained Helm chart. A compatible client protocol does not mean every Redis version, module or stored-data format can be moved unchanged.

For Redis versus Valkey, keep Redis when the application depends on capabilities or support specific to your chosen Redis distribution. Evaluate Valkey when its documented commands, client behavior and support fit the application. Check licenses and versions separately from packaging. A new chart is a way to install the target; it is not the data migration itself.

Inventory the workload

Record engine/version, commands, modules, persistence settings, eviction policy, authentication, TLS, key expiry behavior and client library. Identify whether clients expect a single endpoint, Sentinel discovery or cluster redirections. Include Lua scripts and application assumptions about transactions and retry behavior.

Choose a migration strategy

• Disposable cache: a controlled cold start may be simpler than moving data. Confirm the backing service can withstand cache misses and stagger client traffic.
• Persistent single-primary workload: Valkey documents compatibility with Redis OSS 7.2 and earlier; Redis CE 7.4 and later produce incompatible data files, so direct RDB/AOF transfer is not a supported migration path for those versions. Choose and test a different transfer method when needed. Validate backup format and restore compatibility in the target version, check expiry and counts, then run application-level consistency checks.
• Sentinel or sharded deployment: test discovery, failover and client routing separately. Topology changes deserve their own rehearsal.

Acceptance is application behavior

Exercise authentication, reconnects, failover, memory pressure and representative commands against the target. Compare latency and error behavior under an explicit workload; a successful PING is insufficient. Check that backup, monitoring and fresh-node image pulls work after the move.

Rollback without split writes

Choose which endpoint owns writes during each stage. Sending writes to both systems without a reconciliation design creates divergent state. For durable data, determine how new writes return to the old system or how they are replayed. For a cache, rehearse the traffic surge after reverting or flushing.

No universal Redis-to-Valkey upgrade is claimed here. Review licenses and support for the exact distribution, and use the chart/image inventory before altering volume mounts or entrypoints. The current chart is a deployment option; the workload decides compatibility.