Valkey 9.1 vs Redis 8.4: The Cache Fork Grew Up

Valkey just shipped something Redis hasn’t: hash field expiration. You can now put a TTL on a single field inside a hash — not the whole key, just one field — using HEXPIRE. Redis 8.4 does not have this. That’s the tell. Two and a half years after AWS, Google, and Oracle forked Redis over a license dispute, the fork is no longer just playing catch-up. It’s shipping features its parent hasn’t matched yet, it has its own GUI tooling, and both major cloud providers have already made it their default for new cache instances. The fork grew up.

What Valkey 9.1 Actually Ships

The headline feature landed in Valkey 9.0 and is fully production-ready in 9.1: hash field expiration. Before this, Redis and Valkey both had an all-or-nothing expiry model — you set a TTL on the key, and every field in that hash died with it. If you needed per-field expiry (session tokens with different lifetimes, feature flags per user, per-field refresh windows), the standard workaround was to split your data into separate keys. Messy, memory-hungry, and annoying to reason about.

Valkey 9.1 fixes this with eleven new commands: HEXPIRE, HEXPIREAT, HPEXPIRE, HPEXPIREAT, HPERSIST, HPTTL, HTTL, HGETEX, HSETEX, and their timestamp variants. Under the hood, it uses a volatile set data structure that tracks expiring fields without meaningful overhead on standard hash operations. Here’s what migrating from the old pattern looks like:

# Old workaround: one key per expiring value
SET user:123:session_abc "token_value" EX 3600
SET user:123:refresh_xyz "token_value" EX 86400

# Valkey 9.1: one hash, per-field TTLs
HSET user:123 session_abc "token_value" refresh_xyz "token_value"
HEXPIRE user:123 3600 FIELDS 1 session_abc
HEXPIRE user:123 86400 FIELDS 1 refresh_xyz

The second addition in 9.1 is Valkey Admin, an open-source cluster management GUI. It ships as a desktop app for macOS and Linux, and as a Docker/Kubernetes container. It gives you real-time cluster dashboards, per-node topology, a key browser, hot key detection, and aggregated command logs. Redis has RedisInsight — which is proprietary. Valkey now has its own equivalent, under Apache 2.0. The fork is building an ecosystem, not just maintaining a codebase.

The Benchmark Reality (Stop the Theater)

Every few months, someone publishes a “Valkey vs Redis performance showdown” that declares a clear winner. Don’t trust it without reading the methodology section. The honest picture: Valkey reads faster (GET), Redis writes faster (SET, INCR). The actual differences are in the single-digit to low-double-digit percentage range and depend heavily on workload shape, hardware, and configuration. Valkey 9.1 reaches around 2.1 million requests per second on modern multi-core hardware, with P99 latency roughly 22% lower than Redis in read-heavy scenarios. Memory efficiency is also better — around 20-28% on large sorted sets.

For most applications, none of this is the deciding factor. A cache that returns in 0.3ms versus one that returns in 0.25ms is not your bottleneck. The most honest published benchmark makes this clear: workload-dependent, not a slam dunk either way. Stop letting benchmark theater drive your caching architecture decisions.

The Cloud Already Decided

AWS ElastiCache and Google Cloud Memorystore now provision Valkey by default for new instances — not Redis. AWS’s reasoning is explicit: Valkey is 20% cheaper than Redis OSS on node-based clusters and 33% cheaper on ElastiCache Serverless. If you’re starting a new project on either cloud, you’re getting Valkey unless you actively opt out. Over 700 contributors have joined the project. It’s sitting at 5 million Docker pulls. The Linux Foundation isn’t letting this one die.

That’s the pragmatic argument that bypasses the entire ideological debate about forks and license politics. If your infrastructure costs less and the default choice is open source with no licensing surprises, the decision writes itself for new deployments.

The License Question Still Matters

Redis 8 went back to “open source” via AGPLv3. That’s not nothing — but it’s not BSD either. The AGPL is a copyleft license. If you modify Redis and deploy it as a service without open-sourcing your changes, you’re in murky legal territory. Most SaaS companies either don’t notice this until their legal team does, or they sidestep it by using hosted Redis where the modification clause doesn’t apply to them. Valkey stays BSD — permissive, no strings, no lawyer conversation required.

There’s also a structural asymmetry worth knowing: because Valkey is BSD, Redis’s AGPL codebase can incorporate Valkey contributions. But Valkey cannot pull Redis’s AGPL code back. The fork is legally one-directional. In practice, this means Valkey has to build features independently — which is why HEXPIRE shipping in Valkey before Redis is a legitimately significant milestone, not just a talking point.

What to Do

Starting a new project on AWS or GCP: use Valkey. The cloud defaults, the pricing, the license, and now the feature set all point the same direction. Running Redis in production today: no urgent rush unless you need HEXPIRE or have AGPL concerns — the wire protocol is compatible, and Valkey remains a drop-in replacement when you’re ready to migrate. The one area where Redis 8 still holds an edge is its bundled vector store and integrated search and JSON capabilities from Redis Stack — Valkey’s module ecosystem is still building parity there.

The fork war produced something useful. Two and a half years in, Valkey isn’t a protest — it’s infrastructure.