Redis 8 and Valkey 8 share a lineage, but they are independent projects with different licenses, release paths, bundled capabilities, and compatibility boundaries. A production choice should start with the commands, modules, persistence files, clients, managed platform, and legal obligations the workload actually uses. It should not start with an unverified throughput table.
- Redis 8 is available under a choice of AGPLv3, RSALv2, or SSPLv1 and includes Search, JSON, time series, and probabilistic structures in its binary distributions.
- Valkey is a BSD-3-Clause, vendor-neutral project under the Linux Foundation and is a direct continuation of the Redis OSS 7.2.4 code line.
- Valkey documents protocol, configuration, and persistence compatibility with Redis OSS 7.2 and earlier—not with Redis Community Edition 7.4 or Redis 8 data files.
- Existing RESP2/RESP3 clients often connect to both, but command, module, ACL, cluster, configuration, and managed-service behavior still require testing.
- Benchmark latency, throughput, memory, persistence, and failover with your own dataset and request mix.
Licensing and governance
Redis 8 source code can be used under one of three license choices: the OSI-approved AGPLv3 or the source-available RSALv2 and SSPLv1. The integrated Redis modules are covered by the same tri-license. Redis Ltd. also offers proprietary products under commercial terms. The obligations differ substantially, especially for modified software and network services, so have counsel review the selected license and deployment model.
Valkey uses the BSD 3-Clause license and is governed as a Linux Foundation project. That permissive license and vendor-neutral governance can be decisive for distributors and managed-service providers. Licensing is only one dimension; support ownership, release cadence, security response, and platform availability belong in the decision record too.
Feature scope is no longer identical
| Area | Redis 8 | Valkey 8 |
|---|---|---|
| Core lineage | Redis project release line | Forked from Redis OSS 7.2.4 and developed independently |
| License | Choice of AGPLv3, RSALv2, or SSPLv1 | BSD 3-Clause |
| Data and search features | Search, JSON, time series, and probabilistic structures are integrated in Redis 8 distributions | Core server plus Valkey's own evolving features and module ecosystem; verify each required capability |
| Wire protocol | RESP2 and RESP3 | RESP2 and RESP3, with compatibility documented for the Redis OSS 7.2 lineage |
| Managed operation | Redis products and providers supporting Redis under their terms | Self-managed and multiple managed offerings, including Amazon ElastiCache for Valkey |
Do not infer feature parity from a familiar command name. Inventory MODULE LIST, scripts and functions, ACL categories, configuration directives, keyspace notifications, cluster commands, persistence settings, client-side caching, and operational automation. Read both projects' release notes for the exact source and target versions.
The compatibility boundary that controls migration
Valkey's official migration guide states that Valkey is compatible with Redis OSS 7.2 and earlier because the project forked Redis OSS 7.2.4. For that lineage, the guide documents compatible protocol, configuration, and RDB/AOF formats, plus snapshot, replication, key-copy, and cluster migration paths.
Valkey explicitly says that data files produced by Redis Community Edition 7.4 and later are not compatible and that migration from those versions is outside that guide. Do not copy a Redis 8 RDB or AOF into Valkey, and do not assume cross-project replication is supported. Use a migration method documented by the source, target, or managed provider for the exact versions, or perform a controlled logical/application-level transfer.
Pre-migration inventory
- Record the exact server version and deployment mode: standalone, Sentinel, or Cluster.
- Export configuration through the approved administrative path and record ACLs, TLS, persistence, replication, and cluster topology.
- List modules, functions, Lua scripts, command usage, database numbers, key types, key counts, TTL distribution, stream consumer groups, and pub/sub behavior.
- Confirm client libraries, connection discovery, retry behavior, health checks, and telemetry support the target.
- Capture a recoverable backup and test restoring it to an isolated environment before changing production.
Migration from Redis OSS 7.2 or earlier
For versions inside Valkey's documented boundary, choose between an offline snapshot migration and online replication based on write rate, downtime, topology, and rollback needs. Rehearse the exact process with production-shaped data. During an online migration, monitor link state and offsets, but remember that a matching offset is not application validation.
- Deploy the target with equivalent network controls, TLS, ACLs, persistence, memory policy, and monitoring.
- Load a snapshot or establish replication exactly as the Valkey guide specifies for the topology.
- Compare keyspace totals by logical database and sample values, types, TTLs, stream groups, scripts, and application reads.
- Pause or account for writes during the final boundary, confirm the target is caught up, then promote or cut over through the tested endpoint.
- Run read and write smoke tests, observe errors and latency, and retain the untouched rollback source until the acceptance window closes.
Redis Cluster requires a slot-aware procedure and enough target nodes. Follow the cluster section of the official guide rather than adapting a standalone REPLICAOF example.
Migration from Redis 7.4 or Redis 8
Start with a compatibility lab, not a production replica. Identify a provider-supported online migration, a logical key-transfer tool that understands the source and target, or an application-level dual-write and backfill design. Validate expiration semantics, data types, modules, scripts, transactions, cluster hash slots, and ordering requirements. Establish a clear point after which rollback would require reverse synchronization.
For Amazon ElastiCache, use AWS's documented online migration and engine-transition procedures for supported sources and targets. Managed-service behavior, supported versions, maintenance events, and endpoint changes can differ from self-managed servers.
Benchmark the decision
Run the same client, network path, dataset, persistence mode, memory ceiling, and failover scenario on both candidates. Measure application p50/p95/p99 latency, throughput at a fixed latency objective, CPU, memory, fork and persistence effects, replication lag, recovery, and resharding. Include large keys, scripts, pub/sub, streams, and cluster multi-key operations if the application uses them. Publish the environment with the result; a number without its setup is not portable evidence.
Official primary sources
- Redis licensing overview
- Redis Open Source 8.0 release notes
- Valkey introduction and license
- Valkey migration from Redis documentation
- Amazon ElastiCache online migration
Working with JusDB on Redis and Valkey
JusDB helps teams inventory compatibility, design a reversible migration, validate persistence and failover, and benchmark Redis and Valkey under the same production-shaped workload.
Explore JusDB Redis services → | Talk to a database engineer