Valkey

In March 2024, Redis Ltd. relicensed future Redis releases from BSD to the source-available RSALv2/SSPL pair. Within weeks the community - backed by AWS, Google, Oracle, and the Linux Foundation - forked the last BSD release into Valkey. So Valkey is two things at once: the continuation of the Redis you already know at 7.2, and an independent project that has been diverging since.

What Valkey is

• A BSD-licensed, Redis-protocol-compatible in-memory key-value store: strings, hashes, lists, sets, sorted sets, streams, pub/sub, Lua, modules.
• Drop-in compatible at the 7.2.x baseline: same commands, same wire protocol, same persistence formats - existing clients, libraries, and most modules work unmodified.
• Governed by the Linux Foundation with the licence guaranteed open, which is the point of the fork.

What diverged since the fork

The 8.x line is where Valkey stopped being “just a fork”, and 9.x continues it:

• I/O threading rework (8.x): improved multi-threaded I/O pushed single-node throughput well past the Redis 7.2 baseline.
• Memory efficiency (8.x): per-key overhead reductions, notably in hash and set encodings.
• Hash field expiration (9.0): per-field TTL inside a hash (HEXPIRE, HTTL and the rest of the family), closing a long-standing gap where expiry was all-or-nothing at the key level.
• Cluster-mode scale-out (9.0): atomic slot migration and multiple logical databases in cluster mode.
• New capabilities arriving independently - for example a vector-search module ecosystem (valkey-search) rather than the bundled RediSearch path.

Redis itself continued too - Redis 8 re-added AGPLv3 as a licence option and folded the former modules into core. The practical divergence today: API-compatible for the common surface, but performance characteristics, module ecosystems, and governance are genuinely different tracks.

Migration reality

For a cache or simple KV workload, migration is close to a config change: point the client at a Valkey instance, or load an RDB/AOF from Redis 7.2-era formats. Where it stops being trivial:

• Modules: anything built on Redis Stack modules (RediSearch, RedisJSON, RedisBloom) needs the Valkey-side module equivalent - which may not exist yet or differ in API.
• Newer Redis 8 features: anything adopted post-fork does not exist on the Valkey line.
• Managed services: the cloud provider’s managed offering decides for you - AWS moved its offering to Valkey, others ship their own.

Operations

Operationally identical to Redis 7.2: same config file, same persistence model (RDB snapshots, AOF), same replication and Sentinel/Cluster topology, same diagnostics (INFO, SLOWLOG). Every Redis operational runbook written before 2025 transfers directly.

What actually breaks

• Assuming the fork is a rebrand: newer features diverge in both directions, so “works on Redis 8” does not imply “works on Valkey 8”.
• Module assumptions: a deployment leaning on Redis Stack modules needs a per-module porting check before the swap.
• Confusing licence headlines: Redis’s later AGPL option did not close the governance question for the organisations that forked - evaluate on current terms, not on the 2024 announcement.

Where Valkey is the wrong choice

If you are pinned to Redis Stack modules or Redis 8-specific features, staying on Redis is the lower-friction path. If your need is strictly a disposable cache with zero features beyond get/set, Memcached remains the simplest thing that works. Valkey’s slot is the broad middle: the Redis-shaped data-structure store with a licence and governance model your legal team and your cloud provider can both live with.