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.

import redis                       # the redis-py client works against Valkey
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.

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.

Interview angle

• “What is Valkey and why does it exist?” — a Linux Foundation fork of Redis 7.2.4, created after Redis Inc. moved to source-available licensing (RSALv2/SSPLv1) in 2024. Backed by AWS, Google and Oracle, and now the default on several managed cache services.
• “Would you use Valkey or Redis?” — for a plain cache they’re interchangeable; pick on licence and managed-service price, which usually favours Valkey. Stay on Redis if you depend on Redis Stack modules or Enterprise features.
• “Do you need to change your code?” — no. Valkey is API-compatible with Redis 7.2, so existing clients and commands work. It’s typically a connection-string change.
• “Has Valkey diverged technically?” — yes, notably multi-threaded I/O for higher throughput on multi-core hosts. Redis 8 has its own performance track. The gap is real but not the reason most people choose one.
• “Why did the licence change matter so much?” — SSPL-style terms restrict offering the software as a managed service, which directly affects cloud providers. That’s why the hyperscalers backed a fork rather than accepting the new terms.