Redis and Valkey are closely related in-memory data stores that share the Redis Serialization Protocol and a large set of commands and client-library patterns, but they are no longer one interchangeable project.
For teams choosing between them, the useful questions are application compatibility, operational ownership, persistence and module requirements, licensing/project direction, and how safely an existing Redis workload can be migrated.
This guide owns the Redis-vs-Valkey decision and migration boundary. For hosting choice, use Redis Hosting: Managed Valkey vs Self-Hosted Redis. For cache/queue architecture, use Redis Cache Strategy for SaaS Apps.
Redis and Valkey share a common operational heritage
Valkey began as a fork of Redis OSS 7.2 and continues to use RESP, familiar data structures, persistence concepts, replication, ACLs, transactions, Lua scripting, and common Redis client patterns.
That shared heritage is why many applications can migrate with limited code change.
But compatibility should be tested rather than assumed.
| Area | What to verify before migration |
|---|---|
| Client library | Does the client work against the target Valkey version? |
| Commands | Are all commands used by the application supported with the same semantics? |
| Modules | Are required modules available and compatible? |
| Persistence | Are the source RDB/AOF files supported by the target version? |
| ACL/auth | Do users, permissions, and credential workflows map correctly? |
| Cluster topology | Are slot, replication, failover, and discovery assumptions compatible? |
| Monitoring | Do dashboards and alerts recognize Valkey metrics/identifiers? |
| Automation | Do provisioning and backup scripts rely on Redis-specific packaging or paths? |
The safest migration is based on the exact workload, not a generic compatibility percentage.
Valkey documents direct compatibility with Redis OSS 7.2-era data
Valkey's migration documentation states that Valkey can load Redis OSS 7.2 RDB and AOF files and supports Redis OSS modules using the module API, subject to module compatibility.
That is especially useful for teams migrating older Redis OSS deployments.
Later Redis Community Edition releases have evolved independently. File-level or command-level compatibility across every newer release should therefore be checked against the source and target versions rather than assumed from the shared origin.
A migration plan should record:
source Redis version → client versions → commands/modules in use → persistence format → target Valkey version → compatibility test
Version awareness matters more than the brand names alone.
Application protocol compatibility is only the first layer
An application can connect successfully and still have operational incompatibilities.
Test workloads that depend on:
- Lua scripts;
- transactions and WATCH/MULTI behavior;
- streams and consumer groups;
- sorted sets and blocking commands;
- pub/sub;
- ACLs;
- cluster-mode routing;
- keyspace notifications;
- persistence/restart behavior;
- modules;
- client-side caching or newer protocol capabilities.
Create a representative test suite that exercises the commands actually used in production.
A simple connectivity check such as PING proves very little about migration safety.
Client libraries should be tested for discovery and naming assumptions
Many Redis clients work with Valkey because they speak RESP and use standard commands. Some ecosystems now expose explicit Valkey support or separate Valkey-oriented packages.
Do not change client libraries merely because the server changes if the current library is supported and stable.
Instead verify:
- connection URI format;
- TLS behavior;
- authentication;
- cluster/sentinel-style discovery assumptions;
- retry and reconnect logic;
- command compatibility;
- metrics and error parsing.
The migration goal is the smallest safe change set.
Changing server, client library, topology, and persistence settings at the same time makes rollback and diagnosis harder.
Persistence compatibility needs a deliberate path
Redis and Valkey both support RDB and AOF persistence concepts, but migration should use a supported source-target path.
For a small standalone workload, approaches can include:
- stop source writes, copy a compatible RDB/AOF artifact, start target, validate;
- export/import application data through a migration tool;
- replicate or dual-write through a tested migration workflow;
- rebuild the target entirely when the workload is disposable cache.
The correct path depends on downtime tolerance and whether the data is authoritative.
For cache-only workloads, rebuilding can be safer than carrying old persistence state forward.
For sessions or queues, the team needs a plan for state that cannot simply disappear during cutover.
Redis vs Valkey is also an operating-model decision
The choice is not only about protocol compatibility.
Teams should compare:
| Decision factor | Redis | Valkey |
|---|---|---|
| Existing production standard | Strong if already standardized | Requires migration validation |
| RESP/client familiarity | Strong | Strong |
| Open-source ecosystem direction | Redis project-specific | Linux Foundation-hosted Valkey project |
| Managed service availability | Provider-dependent | Increasing managed-service availability |
| Existing modules/tooling | Verify current Redis ecosystem | Verify Valkey compatibility |
| Team runbooks | Existing Redis runbooks may already exist | Runbooks may need naming/packaging updates |
The business question is whether changing projects creates enough benefit to justify migration work and operational validation.
Migration should reduce simultaneous changes
A controlled migration uses stages.
1. Inventory the source
Record:
- Redis version;
- topology;
- dataset size;
- memory policy;
- persistence mode;
- modules;
- ACLs;
- clients;
- commands used;
- peak operations per second;
- acceptable downtime/data loss.
2. Build the target with equivalent boundaries
Match the relevant:
- memory capacity;
- networking;
- TLS/authentication;
- persistence requirements;
- eviction policy;
- backup/recovery workflow.
3. Test application compatibility
Replay representative traffic or integration tests against Valkey.
Measure:
- command errors;
- latency;
- reconnect behavior;
- queue/stream semantics;
- session behavior;
- memory growth;
- persistence restart.
4. Choose a data-transfer model
| Workload | Typical migration model |
|---|---|
| Disposable cache | Start empty and warm naturally |
| Sessions | Short controlled cutover or compatible data copy |
| Queues | Drain/freeze or migrate pending state carefully |
| Rate limits | Decide whether reset is acceptable |
| Mixed workloads | Separate roles before migration where practical |
5. Cut over with rollback criteria
Define before the change:
- DNS/endpoint switch method;
- source write-freeze window if needed;
- validation queries;
- error-rate threshold for rollback;
- how long the source remains available;
- who approves completion.
Migration is safer when rollback is a planned branch, not an improvised reaction.
A cache migration can be intentionally simpler
When Redis contains only rebuildable cache data, preserving every key may create unnecessary risk.
A clean migration can be:
provision Valkey → validate connectivity/auth → point a small traffic slice at target → switch application → allow cache to warm → monitor origin database load
The main risk becomes cache-miss pressure rather than data loss.
Protect the primary database from a sudden cold-cache stampede by staging traffic, pre-warming expensive keys, or temporarily increasing application-side request coalescing where appropriate.
Queues and sessions require stronger validation
A queue or session store is not as disposable as a read cache.
For queues, validate:
- pending jobs;
- consumer-group state;
- retries;
- idempotency;
- job duplication or loss during cutover.
For sessions, validate:
- TTLs;
- logout impact;
- serialization format;
- authentication behavior after reconnect.
If the migration can cause state loss, quantify it before deciding the cutover method.
Raff's managed Redis-compatible path is Valkey
Raff currently provides Managed Valkey for managed Redis-compatible cache, queues, sessions, and related workloads.
This matters for content and architecture language: Raff should not describe the product as “Managed Redis.” The managed engine is Valkey; Redis can still be self-hosted on Raff VMs when exact Redis control is required.
A practical Raff decision path is:
Need managed Redis-compatible operations → validate application against Managed Valkey Need exact Redis version/modules/host control → self-host Redis on Raff VM
At Raff, the migration rule is to test the exact commands and state the application depends on, then change as few other variables as possible during cutover.
Redis-to-Valkey migration checklist
- Source Redis version is recorded.
- Target Valkey version is selected.
- Client libraries are tested.
- Required commands and modules are inventoried.
- RDB/AOF compatibility is verified if files will be copied.
- ACL/TLS behavior is tested.
- Eviction and persistence settings are mapped.
- Cache, session, queue, and lock roles are classified.
- Data-transfer method matches workload criticality.
- Cold-cache impact is planned.
- Cutover and rollback steps are documented.
- Source remains available until target validation is complete.
Conclusion
Valkey is highly compatible with the Redis OSS lineage, but production migration should be version- and workload-specific.
For many standard cache workloads, migration can be straightforward because the protocol, clients, and command model remain familiar. For modules, persistence files, clusters, queues, and session state, test the exact behavior before cutover.
Choose Valkey when its project and managed-service path fit the workload. Keep Redis when exact Redis-specific requirements justify it. The goal is not to migrate for the label; it is to choose the operating model the team can run and recover confidently.