Valkey 9.1 vs Redis 8.4: The Fork Finally Grew Up

Back in March 2024, when Redis changed its license, the advice most teams got was simple: wait and see. Valkey, the Linux Foundation fork, was brand new. It was essentially Redis 7.4 with a different governance badge, and nobody wanted to migrate a production cache for a license badge.

Two and a half years later, waiting is no longer the neutral option. Both projects have shipped major releases that the other does not have, both shipped security fixes in the same week in late August 2026, and the feature sets have genuinely diverged. If you run a cache in production, you now have a real decision to make, and the interesting part is that the right answer depends on your workload, not on which project has the better governance story.

I went through the release notes on both sides, the Valkey benchmark dashboards, the security advisories, and one important independent benchmark that caught a trap in Valkey's own docs. Full disclosure: my day job is JVM backend work, six years of Spring Boot, and I have not personally run a Valkey-to-Redis migration. I do run Redis in my own AI agent infrastructure, so this decision is on my roadmap. What follows is the research summary I built for that decision.

What Valkey 9.x has that Redis does not

Valkey shipped 9.0 in late 2025 and 9.1 in May 2026, and both releases carry features Redis has not matched.

• Hash field expiration. Valkey 9.0 added HEXPIRE and HPERSIST, so you can put a TTL on a single field inside a hash instead of the whole key. Maintainer Madelyn Olson called it the single most requested feature in the project's history. Redis has no equivalent.
• Atomic slot migration. Valkey 9.0 moves entire cluster slots between nodes using the AOF format instead of copying key by key. Large collections no longer cause latency spikes during resharding. Redis added its own atomic slot migration in 8.4, so this gap closed, but Valkey shipped it first.
• Multiple databases in cluster mode. Numbered databases now work in sharded clusters, which makes multi-tenancy on one cluster practical instead of forcing one instance per tenant.
• Database-level ACLs. Valkey 9.1 lets you scope a user's permissions to specific numbered databases. In Redis, access control is all-or-nothing across the instance. This is the feature that turns one shared cluster into a legitimate multi-tenant platform.
• Lua as a loadable module. If your workload does no scripting, you can disable Lua entirely and shrink your attack surface to zero. That is a real security posture change for pure cache deployments.
• Memory efficiency. Valkey 9.1's per-key memory overhead dropped by 17 to 44 percent for string keys, averaging around 26 percent, with no configuration changes. Sorted set members save up to 8.5 bytes each. On a cache holding tens of millions of small keys, that is either free capacity or a smaller bill.
• Throughput. The redesigned I/O threading model pushed a single Valkey 9.1 server to 2.1 million requests per second on 512-byte payloads, with up to 17 percent throughput gains from the threading redesign and up to 25 percent latency reduction from Multipath TCP support.

What Redis 8.4 has that Valkey does not

Redis did not stand still. Version 8.4 went GA in November 2025, and it is the stronger platform if your cache is doing more than caching.

• FT.HYBRID search. Full-text and vector similarity results fused into one ranked list, using Reciprocal Rank Fusion or linear scoring, inside one query execution. This is the retrieval primitive AI applications keep bolting on from the outside, and Redis moved it into the engine.
• Vector sets with SIMD. VADD and VSIM got AVX2 and AVX512 dot product implementations. Redis is positioning itself as a retrieval engine for AI apps, not just a cache.
• Atomic compare-and-set on strings. SET extensions with IFEQ and IFNE options let you update a key only if its value has not changed since you fetched it, in one command. Anyone who has hand-rolled optimistic concurrency with WATCH and MULTI knows how much ceremony that removes.
• Query engine I/O threading. Multi-threaded I/O for search operations delivered up to 4.7x throughput gains on large-result-set FT.SEARCH workloads.
• JSON memory cuts. Homogeneous JSON arrays use up to 91 percent less memory in 8.4.

The positioning difference is the real story here. Redis 8.4 is a bet that the cache becomes the retrieval layer for AI applications. Valkey 9.1 is a bet that the cache stays a cache and gets cheaper, faster, and safer at doing exactly that.

The security week nobody should ignore

Here is the part that turns this from a philosophy debate into an ops item. Both projects shipped security releases within two days of each other at the end of August 2026.

• Valkey 9.0.6 shipped September 1, 2026, marked SECURITY urgency. It fixes a use-after-free in RDMA connection handling where an authenticated client could crash the server using CLIENT KILL. It only affects servers built with USE_RDMA and configured with an RDMA listener, so most deployments are fine, but check your build flags.
• Valkey 9.1.2 shipped August 31, 2026, also SECURITY urgency.
• Redis 8.4.6 shipped August 17, 2026, and its fix list is longer: CVE-2026-62356, a heap out-of-bounds write during CMSketch RDB loading; an ACL key permission bypass in SORT, GEORADIUS, and stream commands where the validated keys could differ from the keys actually accessed; and multiple Vector Sets bugs including a use-after-free in the HNSW graph during background VSIM.

If you are on either platform and have not patched since mid-August, that is your to-do regardless of which side of the fork debate you sit on. The Redis ACL bypass deserves special attention: any deployment using ACLs as a security boundary, not just as convenience, should treat 8.4.6 as urgent.

The trap in the shiny feature

One independent benchmark made me respect this space a lot more. A Dev.to benchmark tested the headline pattern from Valkey's own blog post: storing per-user auth tokens with HSETEX, the new one-round-trip field-plus-TTL command, instead of the classic SET key value EX 900 string pattern.

The result: giving a single field a TTL forces the hash out of listpack encoding and into hashtable encoding, and the memory cost roughly triples. The new-feature pattern ended up using more memory than the string-per-token pattern it was meant to improve on. Valkey's maintainers know about this; issue #2618 tracks it, and the per-field expiry cost of 16 to 29 bytes matches what the benchmark measured. As of 9.1.2, it has not landed in listpack yet.

The lesson generalizes past Valkey: any cache feature that changes the internal encoding of your data structure can silently rewrite your memory bill. Benchmark your actual access pattern before you adopt a new command, even when the command comes from the project's own launch blog.

The decision framework

Here is how I would choose, based on everything above.

Choose Valkey 9.1 if:

• Your cache is a cache: sessions, rate limiting, feature flags, short-lived computed values.
• You run multi-tenant infrastructure and want database-level ACL isolation on a shared cluster.
• Memory cost dominates. The 17 to 44 percent per-key overhead cut is free money on large string-heavy keyspaces.
• License posture matters to you. Valkey is BSD-licensed under Linux Foundation governance, forever, by charter.
• You are on AWS ElastiCache or GCP Memorystore, both of which support Valkey natively.

Choose Redis 8.4 if:

• You are building or running AI retrieval workloads: semantic search, hybrid full-text-plus-vector queries, RAG pipelines. FT.HYBRID is a genuine differentiator and Valkey has nothing equivalent today.
• You rely on Redis Query Engine, RedisJSON, or time series features as core platform capabilities.
• You want atomic compare-and-set semantics on strings without WATCH/MULTI ceremony.
• Your managed provider is Azure Cache for Redis or you are an existing Redis Enterprise customer, where the commercial relationship matters.

Stay put if:

• You run Redis 7.2 or earlier under the old BSD license and your current version works. Your license has not changed, and neither project has a must-have migration feature for a plain cache workload yet. Patch security releases, revisit when your provider forces a version bump.

One honest note on lock-in: the protocol compatibility runs both ways, so most clients work against both servers. But the new features do not. HSETEX is Valkey-only. FT.HYBRID is Redis-only. The moment you adopt a fork-specific feature, you have made your choice for a while, so treat new commands like schema migrations: adopt deliberately, not because a launch post looked nice.

What I would do next

For my own stack, the path is clear. My agent infrastructure uses Redis for classic session and state caching with no search workloads, so Valkey 9.1 fits, and the memory savings across my small-string keyspace pay for the migration in reduced VPS RAM. But the moment I add semantic caching for LLM responses at scale, Redis 8.4's FT.HYBRID becomes the reason to run Redis for that specific service. There is no rule saying the whole company picks one. The rule is: pick per workload, patch everything to the August and September security releases this week, and benchmark new commands against your real access patterns before adopting them.

I write about backend engineering, caching, and AI infrastructure every week. Subscribe, it is free.

Which one are you running in production, and did the license split change your decision or just your anxiety? Tell me in the comments.

Save this decision matrix: cache-only plus multi-tenant equals Valkey; AI retrieval plus query engine equals Redis; legacy BSD Redis plus working fine equals stay and patch.