Redis vs Valkey: which fits your license, version and features
If your team already runs Redis, the decision on this page turns on three things: the license obligations that apply to how you use it, the Redis version in production, and whether your workload depends on features that only Redis 8 bundles. Redis Open Source is now offered under a choice of AGPLv3, RSALv2 or SSPLv1, while Valkey is BSD-3-Clause and governed under the Linux Foundation. For a team on Redis 7.2 or earlier, moving to Valkey is effectively an upgrade with a well-documented path. For a team on Redis 7.4 or later, the migration is a different exercise, and the choice is less about the fork and more about which license terms and bundled features you need. Redis Open Source fits when you choose the AGPLv3 option and accept its terms, when your application relies on the JSON, time series, probabilistic structures, vector sets or Redis Query Engine that ship with Redis 8, or when you need the Intel SVS-VAMANA vector optimizations, which the Redis README says can only be used under RSALv2. Valkey fits when a BSD-3-Clause license and Linux Foundation governance matter to your procurement or legal review, or when your production base is Redis 7.2 or earlier and you want to stay on a permissive, community-governed line. Confirm with your counsel how AGPLv3 applies if you modify Redis and offer it as a network service, since the Redis licenses FAQ says the modified source must be made available to that service's users.
Start the decision by inventorying your Redis version with redis-server --version on every node, and by listing which data types and modules your application calls. If any node runs Redis 7.4 or later, check Valkey's migration guide before you plan a cutover, because it states that the snapshot and replication methods apply only to Redis 7.2 and earlier. Then document the license position for internal use, for any hosted or customer-facing service, and for any modifications you carry. Ask your vendors which cache they certify: some application vendors now document Valkey rather than Redis in their system requirements, so confirm your application's supported list before you commit.
In short, pick Redis Open Source if you need Redis 8 bundled features and can accept the license terms, and pick Valkey if you need a permissive license, Linux Foundation governance or a clean upgrade from Redis 7.2 or earlier. Whichever you choose, confirm the high availability design in advance: Redis Sentinel and Valkey Sentinel both recommend at least three Sentinel instances for a robust deployment. Your platform team or an implementation partner can then turn those answers into a written scope.
Redis vs Valkey by scenario: which fits your team
This table maps common team profiles to the platform that fits best and the condition that decides it. Read each row against your Redis version, how you distribute software, and whether your vendor already documents Valkey, because those three facts usually settle the choice.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Internal cache on Redis 7.2 or earlier (illustrative) | Valkey, or stay on Redis 7.2 if licensing is acceptable | Redis 7.2 and earlier are BSD-3-Clause, and Valkey is compatible with them, so migration is effectively an upgrade by the migration guide's account |
| Redis 7.4 or later deployment, internal only (illustrative) | Redis Open Source under AGPLv3, or Valkey with a planned migration | Redis 7.4 and later files are not compatible with Valkey, so snapshot and replication methods in the migration guide do not apply |
| Internal service needing Redis 8 JSON or vector search | Redis Open Source 8.x | Query Engine, JSON and vector sets are bundled in Redis 8 and are not part of the Valkey feature set described in the sources |
| Internal use of Redis 8 without vector optimizations | Either, after a license review | Redis Open Source 8 is available under AGPLv3, RSALv2 or SSPLv1 at your choice, and the Intel SVS-VAMANA optimizations require RSALv2 |
| SaaS product offering modified Redis as a network service (illustrative) | Valkey, or Redis under AGPLv3 with a source plan | The Redis licenses FAQ says modified code offered as a network service must be made available to that service's users |
| Unmodified Redis artifacts used internally or by customers (illustrative) | Either, depending on version | The Redis licenses FAQ says teams moving from Redis 7.2 or earlier with unmodified artifacts see no impact |
| Application vendor that already documents Valkey (illustrative) | Valkey | Some vendors, such as Adobe in its Magento requirements, list Valkey rather than Redis, so follow the version your vendor certifies |
| Team that needs a permissive license with Redis-compatible clients | Valkey | Valkey is BSD-3-Clause and existing Redis client libraries connect without code changes, per the migration guide |
How Redis and Valkey are built and what that means for operations
Redis and Valkey share a core architecture, so most operating work is the same on either: a daemon, replication, a high availability layer and optional modules. The differences come from who ships each piece, what license governs it and which tier you buy, so check those before you plan runbooks.
Standalone daemon and host platform
The core is a single in-memory process that you run on a host you manage. Redis Open Source runs natively on Linux, macOS, OpenBSD, NetBSD and FreeBSD, and on Windows only through Docker, so a Windows shop should decide early whether containers are acceptable. Valkey runs the same daemon model. Your team must size memory, set persistence settings and monitor memory use, since the data lives in RAM. Confirm your host OS and container policy before choosing a version.
Replication and backup
A replica copies the primary's data, and replication is the basis for both failover and migration. Your backup plan must cover RDB snapshots and AOF files, and you should test restores on a schedule rather than trusting the files exist. Snapshot formats matter during a move: Valkey reads RDB and AOF files compatible with Redis OSS 7.2, while Redis 7.4 and later produce files Valkey does not read. Check the file format version of your existing backups before you plan a switch.
Sentinel high availability
Sentinel watches a primary and its replicas and promotes a replica when the primary fails, and it applies to deployments that do not use clustering. A robust deployment needs at least three Sentinel instances, placed so that a single host or zone failure cannot remove a majority. Valkey Sentinel provides the same role, and its documentation recommends at least three Sentinel instances. Your team must monitor failover events, test them, and confirm that clients follow the new primary.
Redis Cluster or Valkey Cluster
Cluster mode shards keys across hash slots and runs multiple primaries with replicas, which changes how clients route commands and how multi-key operations behave. You take on slot planning, resharding, node failure handling and client support checks for cluster mode. Valkey Cluster and Redis Cluster share the same general model, but confirm that your client library supports the cluster behavior you need on the version you choose.
Modules and the Redis Query Engine
Redis 8 bundles JSON, time series, probabilistic structures, vector sets in beta and the Redis Query Engine for vector, full-text and geospatial search under the Redis Open Source license choice. Valkey supports modules written for the RedisModule_ API, but bundled search and JSON features are a Redis-side question. Each module adds memory use, upgrade coupling and a license question for internal or hosted use. Inventory which modules your applications call before choosing a platform, and confirm the Intel SVS-VAMANA optimizations are not needed, because they are closed source and only usable under RSALv2.
Redis Software and Redis Cloud
Redis Ltd. sells Redis Software, a self-managed product with added compliance, reliability and resiliency features, and Redis Cloud, a managed service on AWS, Google Cloud and Azure. Neither is open source, so buying them moves you from a license choice to a commercial contract with its own support and terms. Ask for written scope on what is included, what support covers and where data resides. If you keep Redis Open Source in your own infrastructure, you carry the operations yourself.
How Redis and Valkey compare on features and high availability
This table sets Redis Open Source 8.x against Valkey 9.x on license, governance, bundled features, compatibility and high availability. Read the rows that match your license position and your current Redis version first, because those two facts decide most of the migration work.
| Area | Redis Open Source 8.x | Valkey 9.x |
|---|---|---|
| License | Choice of RSALv2, SSPLv1 or AGPLv3 from Redis 8.0 onward. Redis 7.4 to 7.8 remain under RSALv2 or SSPLv1, and 7.2 and earlier under BSD-3-Clause | BSD-3-Clause |
| Governing body | Redis Ltd. steers the project and also sells Redis Software and Redis Cloud, which are not open source | Open community project under LF Projects, LLC, with trademarks held through LF Projects and backed by the Linux Foundation |
| Current release line | Redis 8.10.0 released July 29, 2026, with security releases 8.10.2, 8.8.3, 8.6.7, 8.4.7 and 8.2.10 on September 17, 2026 | Valkey 9.1 stable line, with 9.1.2 published September 1, 2026 and 9.2.0-rc1 on September 16, 2026. Confirm the supported branch you plan to run |
| Bundled JSON, time series and probabilistic structures | Included in the Redis Open Source build, covering JSON, time series, and Bloom, cuckoo, t-digest, top-k and count-min sketch | Confirm with the Valkey project which of these data types and modules ship in your chosen build, since the supplied facts do not cover them |
| Vector and full-text search | Redis Query Engine covers vector, full-text and geospatial search. Vector sets are in beta. Intel SVS-VAMANA optimizations (LeanVec and LVQ) are closed source and usable only under RSALv2, not AGPLv3 or SSPLv1 | Confirm with the Valkey project whether equivalent search and vector capabilities are available. The SVS-VAMANA optimizations are not available to Valkey under this license model |
| Client compatibility | Standard Redis client libraries connect without changes | Existing Redis client libraries connect without code changes, according to Valkey's migration guide |
| Module compatibility | Native modules use the RedisModule_ API that Redis ships | Modules written for the RedisModule_ API work in Valkey, according to Valkey's migration guide. Test each module you depend on before cutover |
| RDB and AOF file compatibility | Redis 7.4 and later produce data files that Valkey cannot read. Redis 7.2 and earlier files are compatible with Valkey 7.2 or later | Reads and writes RDB and AOF files compatible with Redis OSS 7.2. Use replication or key-level MIGRATE for Redis 7.4 and later |
| High availability options | Redis Sentinel for non-cluster deployments, with at least three Sentinel instances recommended. Redis Cluster for sharding | Valkey Sentinel for non-cluster deployments, with at least three Sentinel instances recommended. Valkey Cluster for sharding and replication |
| Platform support | Linux, macOS, OpenBSD, NetBSD and FreeBSD. Windows only through Docker | Confirm supported operating systems and container images with the Valkey project for your target platform |
What the Redis license choice obligates and what Valkey removes
Redis Open Source 8.0 and later can be used under a license of your choice: RSALv2, SSPLv1 or AGPLv3, effective from the general availability release of Redis 8. The choice you make determines what you owe when you modify the code, offer it to others as a service or ship binaries. Each license's text governs its own terms, so the choice should be recorded for each deployment.
- Internal use: Running Redis inside your own organization is the simplest case, but the internal-use wording still differs between the three licenses and should be read in full.
- Modified code as a network service: The Redis licenses FAQ says the modified source must be made available to that service's users. AGPLv3 is the option whose copyleft terms apply to this case.
- Vector optimizations: The Redis README states that the Intel SVS-VAMANA optimizations (LeanVec and LVQ) are closed source and can only be used under RSALv2, so choosing AGPLv3 or SSPLv1 means giving them up.
- Binary distribution: Shipping Redis inside a product or appliance brings the chosen license's distribution conditions into play, which can differ from internal use.
- Community context: The Redis licenses page says Redis Ltd. plans to keep Redis Open Source under AGPLv3, which gives a stable option for teams that need an OSI-approved license.
Have counsel confirm the license applied to each release you deploy, because the artifact you run determines which terms apply.
Redis 7.4.x to 7.8.x, then called Redis Community Edition, remain under the dual RSALv2 or SSPLv1 license. Neither license is OSI-approved, and the AGPLv3 option available from Redis 8 does not apply to this range. Teams on these versions do not get the license choice that Redis 8 offers, so their obligations are fixed by the two source-available licenses.
- Fixed license pair: You must comply with RSALv2 or SSPLv1 in full, and the Redis licenses page does not offer an AGPLv3 alternative for this line.
- Internal use: Internal operation should be checked against both license texts, since the page treats them as the governing terms for this range.
- Network services: SSPLv1 contains its own service-level conditions for offering software to third parties, so read its text directly before running Redis as part of a hosted offering.
- Binary distribution: Redistributing binaries from these versions brings in both license conditions, and product teams should confirm which one applies to their distribution model.
- Migration boundary: Valkey's migration guide says Redis Community Edition 7.4 and later produce data files that are not compatible with Valkey, so the snapshot and replication methods in the guide do not apply here.
Book a counsel review of the RSALv2 or SSPLv1 terms before you keep these versions in production, and check whether a planned upgrade changes the license applied to your deployment.
Redis 7.2.x and earlier remain under BSD-3-Clause, which is a permissive license approved by the Open Source Initiative. The Redis licenses FAQ says teams moving from Redis 7.2 or earlier with unmodified Redis artifacts see no impact from the license change. This is the one Redis line that stays under the same terms as the Valkey fork.
- Unmodified artifacts: Running official, unmodified binaries from this range carries no new license obligations according to the Redis licenses FAQ.
- Modified code: BSD-3-Clause requires that the copyright notice and license text be kept, and it does not, in its standard form, require publishing source for modifications. Confirm this reading with counsel for your specific use.
- Network service: The FAQ's source-availability requirement for modified network services applies to the source-available licenses, so this line does not carry that requirement under its BSD terms.
- Support currency: The supplied facts do not give an end-of-life date for this line, so ask Redis Ltd. for the support window and security policy in writing before you plan to stay on it.
- Migration path: Valkey is compatible with Redis OSS 7.2 and earlier, and the migration guide describes moving from 2.x through 7.2.x to Valkey 7.2 or later as effectively an upgrade.
Before committing to this line, confirm its support window with the provider and review the Valkey migration guide to compare the four documented migration methods.
Valkey is licensed under BSD-3-Clause and was forked from open-source Redis right before Redis moved to source-available licenses. It is an open community project under LF Projects, LLC, and the Linux Foundation holds the Valkey trademarks. Choosing Valkey removes the need to track the RSALv2 and SSPLv1 terms for the Redis 7.4 and later line, while keeping a permissive license for internal, network and binary use.
- Permissive terms: BSD-3-Clause requires keeping the copyright notice and license text in redistributions and bars using contributor names to endorse derived products.
- Network services: The BSD-3-Clause text does not contain a source-disclosure requirement for hosted modifications, but counsel should confirm this reading for your offering.
- Client compatibility: Existing Redis client libraries connect to Valkey without code changes, and modules written for the RedisModule_ API work in Valkey according to the migration guide.
- Feature confirmation: Redis-only features such as the Redis Query Engine, vector sets or the SVS-VAMANA optimizations should be checked against Valkey's current feature set before you migrate.
- Release lines: Valkey maintains several release lines at once, including 9.1.2, 9.0.6, 8.1.10 and 8.0.11, so pin the line that matches your support policy.
Ask your provider whether the Valkey release line you run is covered by your security process, and confirm that the features you rely on exist in it.
Redis Ltd. sells Redis Software, a self-managed product with added compliance, reliability and resiliency features, and Redis Cloud, a managed service on AWS, Google Cloud and Azure. Neither is open source according to the Redis README. Buying either product changes who holds operational responsibility and adds a commercial agreement on top of the open-source license terms.
- Redis Software: You pay Redis Ltd. for the self-managed product and still run it in your own infrastructure, so the license fee is one cost and your hosting and staff time are another.
- Redis Cloud: You pay the managed service fee and the cloud provider's charges for the environment, and the provider operates the service on the cloud you choose.
- Valkey support: The supplied facts list no paid Valkey edition, so confirm commercial support options directly with each provider you consider.
- Quote inputs: Ask for written terms that state the license covered, the support window, included features, data residency and exit terms.
- Cost drivers: Node or instance count, deployment size and the features you need in the paid tier are the main factors that change the total.
Request a written quote and have counsel review the commercial and license terms together before you sign.
What drives the running cost of Redis and Valkey
The running cost of either option is set less by the license than by the topology you choose and the people who operate it. Both Redis Open Source and Valkey are free to download under their licenses, so the recurring spend comes from the servers that host replicas, Sentinels or cluster nodes, from the staff time to operate persistence and failover, and from any paid support or product you add. Redis Sentinel and Valkey Sentinel both document at least three Sentinel instances for a robust deployment, so a standard high availability layout means at least three extra processes on top of the data nodes, usually spread across separate hosts or failure domains. Ask any provider you deal with to price that footprint explicitly rather than folding it into a per-node figure.
Persistence and failover drive most of the operating skill. Someone has to choose RDB snapshots, AOF or both, size the memory headroom those choices need, test failover, and watch replication lag. The commercial Redis products are a different cost line: Redis Software, which Redis Ltd. describes as a self-managed product with added compliance, reliability and resiliency features, and Redis Cloud, its managed service, are not open source and carry their own fees. If your team relies on the Redis-specific features bundled in Redis 8, confirm in writing whether they need a paid product, and whether the open source build you plan to run includes them under the license you select. Support for Valkey comes from the vendors and service providers that back it, and the Linux Foundation project does not sell a support contract itself, so confirm each provider's support window and escalation path in writing.
One-time costs cluster around the move and the first release cycle: migration testing, client library validation, rollback rehearsal and the documentation your operators need. Recurring costs cover hosting, patching, monitoring, and the upgrade work that follows each release line, since Valkey maintains several lines at once and Redis publishes security releases across multiple branches. When you request a quote, ask for the written scope of migration testing, including which Redis version you run today and whether it is 7.2 or earlier or 7.4 or later, the rollback plan and its tested time limit, the support window covered by the quote, and how upgrades to future release lines are priced. DeployOpen does not publish a price list. A quote follows from the written scope, which is why these details belong in the scope document before any work starts.
Redis vs Valkey migration: what transfers and what gets rebuilt
This sequence moves a Redis 7.2 or earlier deployment to Valkey with a method matched to your topology, confirms the data and clients behave correctly, and leaves a tested rollback path until the cutover is accepted. Redis 7.4 and later need a different method that the Valkey guide does not cover.
Confirm the Redis version and data file type
Before choosing a method, record the exact Redis server version on every node, including replicas and cluster members, and confirm it is 7.2.x or earlier. Valkey's migration guide states that Redis Community Edition 7.4 and later write data files that are not compatible with Valkey, and the snapshot and replication methods in the guide apply only to Redis 7.2 and earlier. If any node runs 7.4 or later, stop here and ask Valkey and your DeployOpen engineer which method applies, because the guide does not cover it. Done when every node's version is written down and each one is in the supported range.
Inventory clients, modules and Redis-only features
Build a list of every application connecting to Redis, the client library and version each uses, any RedisModule_ modules loaded, and any feature that depends on Redis-only capabilities such as the JSON, time series, probabilistic structures, vector sets or Redis Query Engine. The Valkey guide says existing client libraries connect without code changes and modules written against the RedisModule_ API work in Valkey, but it does not promise that every Redis-only feature has a Valkey equivalent, so each dependency needs a named owner and a yes or no answer. Done when the inventory is signed off by the application owners.
Choose one of the four documented methods
Match the method to your topology. An RDB snapshot copy is the simplest path but requires downtime while Redis stops and Valkey loads the data. REPLICAOF replication followed by promotion avoids a full stop but can lose writes that reach the Redis primary during sync, so it needs a write freeze or an accepted loss window. MIGRATE moves selected keys and suits partial moves. For clusters, add Valkey nodes as replicas and promote them with CLUSTER FAILOVER. Record the choice and its write-loss or downtime implications in the change plan. Done when the plan names the method, the maintenance window owner and the approver.
Stage Valkey and copy or replicate the data
Install a Valkey release in a non-production environment that mirrors production, then run the chosen method there first. For snapshot copy, transfer the RDB file and start Valkey with it. For replication, point a Valkey node at the Redis primary with REPLICAOF and wait until the replica reports a complete sync. For clusters, add Valkey nodes as replicas of the Redis primaries. Confirm key counts and sample values match between source and target. Done when the staging run completes and a written comparison shows matching key counts and sampled values.
Rebuild Sentinel or cluster configuration and monitoring
Redis Sentinel and Valkey Sentinel are configured separately, so recreate the Sentinel layer on Valkey with the same quorum intent, and the Valkey Sentinel docs recommend at least three Sentinel instances when not using Valkey Cluster. Update connection strings, service discovery entries, health checks, dashboards and alert rules so they target the Valkey nodes and expose the same signals you monitored on Redis. Remove or retarget any tooling that parses Redis-specific output. Done when a test failover is triggered in staging, the Sentinels promote a replica, and monitoring shows the new primary.
Cut over and promote the Valkey primary
During the approved window, stop writes to Redis if the method requires it, let the final sync complete, and promote Valkey (with REPLICAOF NO ONE for replication or CLUSTER FAILOVER for cluster nodes). Repoint applications to Valkey and keep the Redis nodes running but out of service so rollback remains possible. Watch error rates, latency and client reconnect counts during the first traffic period. Done when the application team confirms normal operation and the write-loss check from the plan has been recorded.
Validate data, behavior and backups
After cutover, compare key counts, sampled values, expiry settings and any module-backed data against the pre-cutover baseline. Run the application test suite and the feature checks from the inventory, paying attention to Redis-only features that may not behave identically. Take a fresh snapshot on Valkey and confirm it restores into a test instance, since your backup job and restore runbook must now point at Valkey. Done when validation results and a successful restore test are filed with the change record.
Hold rollback and retire Redis on a documented schedule
Keep the Redis nodes and their data available for a rollback period agreed in the plan. Rollback means repointing applications to Redis and accepting that writes made on Valkey after cutover are not automatically copied back, so decide in advance how those writes are handled. Only after the agreed period and a clean validation review, decommission the Redis nodes, remove their credentials and update the asset inventory and runbooks. Done when the decommission record is approved and no service references the Redis endpoints.
Where Redis and Valkey implementation projects run long
A single primary with replicas and Sentinel is the most common Redis layout for caches, session stores and queues. The migration work is usually modest in code terms because Valkey is compatible with Redis OSS 7.2 and earlier, and existing Redis client libraries connect without code changes. The schedule risk sits in operations: confirming the data file format, choosing a cutover window and proving failover works before production depends on it. Sentinel is built for a single primary with replicas, and the Valkey Sentinel docs recommend at least three Sentinel instances for a robust deployment, so a two-node pair is a finding to fix before cutover.
- Data format check: Confirm whether the running version is 7.2 or earlier. The migration guide says Redis Community Edition 7.4 and later write data files that Valkey cannot read, so the snapshot and replication methods do not apply.
- Sentinel topology: Verify at least three Sentinel instances on separate hosts or failure domains, with quorum settings your clients understand.
- Client compatibility tests: Run the application's connection, pipelining, pub/sub and eviction paths against a Valkey build before any production change.
- Failover testing: Force a primary failure in staging and measure whether clients reconnect to the new primary and whether any writes were lost during promotion.
- Cutover coordination: A physical RDB migration needs downtime while Valkey loads the data, and replication-based migration can lose writes that arrive during sync, so agree the write freeze with application owners.
Before committing, ask your team to confirm the exact Redis version, the Sentinel count and whether any client library pins a Redis-specific behavior.
Clustered deployments shard keys across hash slots, so migration is a node-by-node exercise rather than a single file copy. The guide's cluster method adds Valkey nodes as replicas of existing shards and promotes them with CLUSTER FAILOVER, which keeps the cluster online but multiplies the number of moving parts. Teams most often lose time on multi-key operations and client routing, since code that assumed keys could live anywhere must be checked against the slot layout. Failover drills also take longer because every shard must be tested, not just one primary.
- Topology inventory: Map every shard, replica and node address, and record which version each one runs before planning the first replica addition.
- Multi-key and script review: Find commands and Lua scripts that touch keys across slots, since those depend on hash tags and may need rework.
- Client routing tests: Confirm the cluster-aware client library handles redirects and topology refreshes during failover.
- Shard-by-shard failover: Promote replicas one shard at a time and check replication lag and error rates between steps.
- Rollback path: Keep the original nodes running until every shard has been verified on the new engine.
Ask your team to confirm the cluster version on each node, because mixed-version nodes can complicate the migration sequence.
Some application vendors now document Valkey rather than Redis, and the choice is made for you by the platform's support matrix. Adobe's system requirements for Magento Open Source 2.4.9 list Valkey 9 as the cache dependency, and 2.4.8-p5 lists Valkey 8.1, with no Redis row in either table. In this case the question is not which engine to adopt in the abstract but which engine version the vendor supports and whether your current Redis version is on that list. Delays come from coordinating the engine version with the application upgrade, not from the cache itself.
- Support matrix alignment: Compare your application release with the vendor's documented cache engine and version before scheduling any engine change.
- Application owner sign-off: Agree who approves the engine change, since the application team may need to retest checkout, caching and session flows.
- Shared instances: Check whether several applications use the same cache, because one engine change then affects every owner.
- Staging parity: Build a staging environment that matches production memory settings, persistence and eviction policy, because cache behavior is often where tests miss problems.
- Upgrade sequencing: Plan the application upgrade and the engine change as separate, reversible steps with a documented rollback.
Ask the application vendor in writing which cache engine and version the release supports, and confirm it against your deployment.
Questions buyers ask before choosing or migrating Redis or Valkey
Is moving from Redis 7.2 to Valkey effectively an upgrade?
Yes, for the Redis versions covered by Valkey's migration guide. The guide says Valkey is compatible with Redis OSS 7.2 and all earlier open-source Redis versions, and that moving from Redis OSS 2.x through 7.2.x to Valkey 7.2 or later is effectively an upgrade. Existing Redis client libraries connect to Valkey without code changes, and Valkey reads and writes RDB and AOF files compatible with Redis OSS 7.2 (Valkey: Migrating from Redis). Confirm that your client libraries and any loaded modules were tested against the Valkey version you select, because compatibility claims cover the server and standard protocol, not every custom build.
Does a move from Redis 7.4 or later to Valkey need a different method?
Yes. Valkey's migration guide warns that Redis Community Edition 7.4 and later produce data files that are not compatible with Valkey, so the snapshot and replication methods in the guide apply only to Redis 7.2 and earlier. Migrating from 7.4 or later requires a different method that the guide does not cover, so plan a test migration and validate data before you commit. The version you run today is the single biggest driver of migration effort, and it should be confirmed on every instance, including replicas and cache nodes.
What drives the effort of a Redis to Valkey migration?
The effort depends mainly on four factors: the Redis version in use, the topology (standalone, Sentinel or cluster), the number and type of client libraries, and how much downtime and write loss the service can tolerate. Valkey's guide describes four methods: copying an RDB snapshot, replication with REPLICAOF followed by promotion, key-level MIGRATE for selected keys, and, for clusters, adding Valkey nodes as replicas and promoting them with CLUSTER FAILOVER. Each method trades downtime against complexity. A physical RDB migration needs downtime while Redis stops and Valkey loads the data, and replication-based migration can lose writes that arrive on the Redis primary during sync, so the write-loss risk needs an explicit plan.
How long does a migration take?
No duration can be stated reliably from the sources available to this page, because it depends on dataset size, write rate, topology and how many services connect to the cache. The biggest variables are the time to load a full RDB file for a physical migration, the time for a replica to finish synchronization, and the testing cycle for each application that uses Redis. Ask for a timeline that is tied to a written scope, with named environments, cutover windows and a rollback point, rather than a generic estimate. Application vendors also change their requirements over time. Adobe's Magento Open Source 2.4.9 system requirements list Valkey 9 as the cache dependency with no Redis row, so check your own application's documentation before you assume a version.
Can our own team migrate Redis to Valkey without outside help?
A team with Redis operations experience, a current inventory of clients and a staging environment can often do a standalone migration in-house, especially on Redis 7.2 or earlier. The harder cases are clusters, Sentinel topologies with strict write-loss requirements, and Redis 7.4 or later data where the guide's standard methods do not apply. Ask yourself whether you can run a rehearsal, measure write loss, and execute a rollback under a change window. DeployOpen plans, implements and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. Ask any provider for a written list of what they will test, not only what they will migrate.
What does the migration need from our team?
Plan for four inputs: test environments that match production topology, a complete client inventory, a validated rollback window, and named owners for application testing. The client inventory should list every library, service and job that connects to Redis, including monitoring agents and scheduled scripts that may use commands with different behavior. The rollback window should state how long the original Redis instance stays available and how you revert if application checks fail. Note that some Redis-hosted data may be ephemeral cache content, which lowers the cost of rollback, while session stores, queues and rate limiters need stricter validation. Each of these inputs should appear as a line item in a written scope before work starts.
What does an AGPLv3 choice mean for an internal Redis service?
For internal use, running unmodified or modified Redis Open Source for your own staff does not, on its own, trigger the network service obligation. The network obligation applies when you offer modified Redis code as a network service, and then the modified source must be made available to that service's users. Redis Open Source 8.0 and later can be used under RSALv2, SSPLv1 or AGPLv3 at your choice, effective from the general availability release of Redis 8, according to the Redis licenses page (Redis licenses). Have your legal team confirm the obligations for your specific architecture, especially if you expose a patched cache to customers or partners. Redis 7.2 and earlier remain under BSD-3-Clause, so a move from those versions to Valkey does not change the license you rely on.
Does Valkey include the search, JSON and vector features that Redis 8 bundles?
Check this before you migrate, because the sources for this page do not establish that Valkey ships equivalents to Redis 8's bundled features. Redis Open Source includes JSON, time series, probabilistic structures, vector sets in beta and the Redis Query Engine for vector, full-text and geospatial search, according to the Redis README (redis/redis GitHub repository). Redis also states that the Intel SVS-VAMANA optimizations are closed source and can only be used under RSALv2. If your application depends on those features, ask the Valkey project and your application vendor for the exact modules and versions supported, and test the queries you run in production.
How DeployOpen helps choose, implement or migrate Redis or Valkey
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Redis vs Valkey, the work starts with a written review of your current Redis version, license obligations and high availability design, then moves to a fixed-scope build or migration.
How we scope
- Confirm your exact Redis version, since 7.2 and earlier and 7.4 and later follow different migration paths.
- Record how you use Redis internally and whether any modified Redis code is offered as a network service.
- Document which features you depend on, such as JSON, vector search or Sentinel, before choosing a target.
- Agree deliverables, timelines and exclusions in writing before any work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen Redis or Valkey topology in your environment, standalone, Sentinel or cluster, as agreed in scope.
- Configure replication, persistence and at least three Sentinel instances where Sentinel high availability is in scope.
- Test client compatibility and the migration method you selected, including failover behavior under load.
- Harden access controls, network exposure and backups, and check the results against your own requirements.
How we hand over
- Provide documentation of the deployed topology, configuration keys, migration steps and rollback procedure.
- Walk your platform and security teams through failover tests and the operating runbook.
- Record the license position for internal and hosted use so your legal and procurement teams hold a written reference.
- Deliver evidence of configuration and testing that your own auditors can review, without issuing any attestation ourselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan minor and security upgrades for your chosen line, such as the release lines you confirm with the maintainers.
- Re-test failover and backups after each version change or topology change in your environment.
- Review any future license or feature changes with you so the platform choice stays documented and current.
