Valkey

The Redis fork. Worth knowing because the licence change is a genuine interview topic — it tests whether you follow the ecosystem, not just the API.

What happened

In March 2024 Redis Inc. relicensed Redis from BSD to a dual RSALv2 / SSPLv1 model. Both are source-available rather than open source: they restrict offering Redis as a managed service.

The Linux Foundation forked Redis 7.2.4 — the last BSD-licensed version — as Valkey. AWS, Google Cloud, Oracle and Ericsson backed it immediately. Managed services largely moved: AWS ElastiCache and MemoryDB now offer Valkey, typically at a lower price than their Redis equivalents.

Redis Inc. later added AGPL as an option, but by then the fork had momentum and adoption.

What it means practically

Valkey is API-compatible with Redis 7.2. Existing clients, commands and data structures work unchanged. For most applications, switching is a connection-string change.

# the redis-py client works against Valkey
import redis
r = redis.Redis(host="valkey.internal", port=6379)

The divergence since the fork:

Valkey’s headline technical work has been multithreading the I/O path, giving significant throughput gains over single-threaded Redis on multi-core machines. Redis 8 has pursued its own performance work in parallel.

The one thing worth checking before a migration is whether you use anything the fork does not carry:

valkey-cli INFO server | grep -E 'valkey_version|redis_version'
# valkey_version:8.1.1
# redis_version:7.2.4        <- compatibility level it reports

# empty means no Stack dependency
valkey-cli MODULE LIST

MODULE LIST is the real gate. Empty output means the migration is a connection-string change; anything listed there — RediSearch, RedisJSON, RedisTimeSeries — is the lock-in, and you need an equivalent before moving.

Choosing

• New project on a cloud provider → Valkey. Cheaper on managed services, permissively licensed, actively developed.
• Existing Redis deployment → no urgency. It still works; the licence only bites if you’re reselling it as a service.
• Dependent on Redis Stack modules (RediSearch, RedisJSON, vector search) → check equivalents before switching. This is the main lock-in.
• Redis Enterprise features (active-active geo-replication, tiered storage) → stay with Redis.

The honest position: for a cache — which is the overwhelmingly common use — they’re interchangeable, and the decision is licence and price. For a Redis-Stack-dependent search or vector workload, the modules matter more than the core.

Everything else transfers

Data structures, persistence (RDB/AOF), replication, cluster mode, eviction policies, pipelining, Lua scripting, Streams — all identical to Redis 7.2 semantics. The material in Redis applies directly, including cache stampede handling and the Redlock critique.

Which is the useful framing for an interview: this is a licensing and governance story, not a technical one. Don’t overstate the differences.