Valkey vs Redis in 2026: The Fork Quietly Won Most of the Market

Valkey vs Redis is the rare infrastructure debate where you can check who is winning by typing one command. On Ubuntu 24.10 and Debian 13, apt install redis-server does not install Redis anymore. It installs Valkey. Homebrew replaced the redis formula with valkey. AWS ElastiCache defaults new clusters to Valkey. The fork that started as an angry reaction to a license change in March 2024 is now the default in-memory data store on most of the internet's default platforms.

And yet Redis is not dead, not closed-source, and in at least four situations it is still the correct choice. I spent the last few days reading the release notes, the benchmarks, and the migration case studies so you don't have to. Full disclosure: I have not personally run a large production migration between the two. Everything below comes from public sources, and I will point at each number's origin.

The two-minute history

The split happened because of licensing, not technology.

• Up to Redis 7.2.4, Redis shipped under BSD 3-Clause, the permissive license that made it ubiquitous.
• March 2024: Redis Ltd. announced that from version 7.4, Redis would move to a dual RSALv2 / SSPLv1 license. Neither is OSI-approved. Cloud providers could no longer offer Redis as a managed service without a commercial agreement.
• Within days, the Linux Foundation forked Redis 7.2.4 as Valkey, keeping the BSD license. AWS, Google Cloud, Oracle, Ericsson, and Snap backed it.
• May 2025: Redis 8.0 added AGPLv3 as a third license option. AGPLv3 is OSI-approved, so by the standard definition, Redis is open source again. This is the detail most 2024 hot takes get wrong.

So the framing "Redis is not open source anymore" stopped being accurate a year and a half ago. The real question in 2026 is different: given two healthy, actively developed, largely compatible engines, which one fits your workload, your legal department, and your cloud bill?

Performance: the gap is real but narrow

Valkey's performance work since the fork has been aggressive. Valkey 8.0 moved connection handling and write-buffer flushing onto dedicated I/O threads while keeping command execution single-threaded, which preserves Redis's predictable atomic semantics. Valkey 8.1 redesigned the hash table and cut roughly 16 bytes of overhead per key. Valkey 9.0 added pipeline memory prefetching and SIMD acceleration (AVX512 on x86, NEON on ARM) that requires no configuration.

The numbers from a March 2026 migration guide on sanj.dev, comparing Redis 8.2 against Valkey 8.1:

• Single-threaded SET throughput: Redis 142,000 ops/s vs Valkey 154,000 ops/s, about 8 percent higher.
• Single-threaded GET throughput: Redis 155,000 ops/s vs Valkey 168,000 ops/s, again about 8 percent.
• Pipelined SET (batch of 10): Redis 580,000 ops/s vs Valkey 812,000 ops/s, roughly 40 percent higher.
• Pipelined GET (batch of 10): Redis 620,000 ops/s vs Valkey 855,000 ops/s, roughly 38 percent.
• P99 latency under load (pipelined): Redis 4.2 ms vs Valkey 2.8 ms, a 33 percent reduction.
• Memory overhead (1M keys, 64B values): Redis 198 MB vs Valkey 191 MB.

AWS's own reporting claims up to 40 percent higher throughput for pipelined workloads on Valkey 9.0, which lines up with the independent numbers above.

How much does this matter to you? If your app issues commands one at a time, the difference is about 8 percent. That almost never changes an architecture decision. If you batch commands on latency-sensitive paths, and you should, a 40 percent pipelined throughput gain is the difference between adding nodes and staying put. Redis did not stand still: Redis 8.8 added batched prefetch for MGET, MSET, and HGETALL. But the momentum on the performance side is clearly with Valkey.

One caveat so you don't repeat a LinkedIn myth at your next planning meeting: Valkey's RDMA support is real but experimental, Linux-only, no TLS, and incompatible with replication links. It matters to a small set of specialized single-node deployments. It is not a reason to migrate.

Cost: Snap's 60 percent cut, translated to your scale

The most cited case study is Snap Inc. At roughly 5 billion daily Redis requests, their infrastructure cost about 2.1 million dollars per year before the license change, mixing self-managed clusters and Redis Ltd. commercial licensing. After migrating to Valkey, that dropped to 840,000 dollars per year, a 60 percent reduction.

The savings break down into three parts:

• Zero licensing fees. Valkey is BSD 3-Clause. No per-node, per-cluster, or per-feature licensing.
• Fewer nodes. The throughput gains let Snap shrink from 180 cluster nodes to 162 for the same load.
• Memory efficiency. Lower per-key overhead meant fewer shard rebalances.

Most of us are not Snap. But the same math compresses down: a 10-node cluster at 2,400 dollars per node per month becomes a 9-node Valkey cluster with zero licensing, roughly 25 percent saved on hardware alone, before any licensing savings if you were paying for Redis Stack or Redis Enterprise. On AWS ElastiCache, Valkey instances run about 20 percent cheaper than the equivalent Redis instance class for the same hardware.

If your Redis bill is 50 dollars a month, none of this moves your life. If it has a comma in it, it does.

Where Redis still wins: the module gap

This is the part most comparisons skip, and it is the actual decision driver for a lot of teams. Redis 8 absorbed the entire Redis Stack into core: JSON, Time Series, the Query Engine for search, Vector Sets, and the full RedisBloom set including Cuckoo filters, Top-K, and T-Digest.

Valkey ships equivalents as separate BSD-licensed modules: valkey-json, valkey-bloom, valkey-search, and a valkey-bundle container that deploys them together. Coverage is not uniform.

• JSON is near parity. valkey-json implements almost the complete JSON command set with JSONPath support.
• Search is a genuine subset. valkey-search exposes six commands: FT.CREATE, FT.SEARCH, FT.AGGREGATE, FT.INFO, FT.DROPINDEX, and FT._LIST. Autocomplete, synonyms, spellcheck, index aliasing, query profiling, cursors, and relevance ranking are all missing. If your search layer uses any of those, Valkey is not a drop-in replacement.
• Probabilistic structures have a hard wall. Valkey has Bloom filters, but there is no Cuckoo filter, Top-K, or T-Digest support at all. No client can fake these, because the server commands simply do not exist. If your rate limiting or frequency estimation relies on them, that is a blocker to find during evaluation, not during a cutover.

On the other side of the ledger, Valkey has capabilities Redis lacks: experimental RDMA, and a roadmap that includes active-active CRDT replication, which would make it the only in-memory store with built-in multi-region CRDT support. Neither is available in any Redis version.

The license question, stated honestly

For most engineering teams, the license argument in 2026 is not about cloud providers at all. It is about your own legal department.

• Valkey: BSD 3-Clause. Permissive, no copyleft, no restrictions on how you deploy or sell around it. The simplest possible position for organizations with strict distribution policies.
• Redis: tri-licensed, and you pick one. RSALv2 is permissive but bans offering Redis as a managed service. SSPLv1 is copyleft with broad service-side obligations. AGPLv3 is strong copyleft: modify the source and serve it over a network, and you may owe your modifications back.

The practical trap is AGPL. Many companies carry blanket policies banning AGPL dependencies, regardless of whether normal use would ever trigger the obligations. If your employer is one of them, Redis 8's AGPL option is a non-starter on paper, and that policy, not any technical judgment, is what pushes a large share of enterprises to Valkey.

One option to explicitly rule out: staying on Redis 7.2.4, the last BSD release. It works, but community security backports to that line are not guaranteed indefinitely, and Redis Software 7.2 hit end-of-life on February 28, 2026. Freezing a data store accumulates risk faster than most teams expect.

The migration is almost embarrassingly easy

If your workload uses core data structures (strings, hashes, lists, sets, sorted sets, streams, HyperLogLog) plus standard pub/sub, migration is a one-line change. Valkey speaks the Redis wire protocol, reads Redis AOF and RDB files, and accepts the same connection string format. Every major client library, including Jedis, Lettuce, redis-py, ioredis, and go-redis, connects without modification. Redis Insight works against Valkey too.

The swap in docker-compose is just the image line:

# Before
services:
  cache:
    image: redis:7.2-alpine
    ports:
      - "6379:6379"
    command: redis-server --appendonly yes

# After
services:
  cache:
    image: valkey/valkey:8.1-alpine
    ports:
      - "6379:6379"
    command: valkey-server --appendonly yes

For zero-downtime migration, use the same replication playbook you would use to promote any Redis replica:

# 1. Point the new Valkey instance at your Redis primary
redis-cli -h valkey-host REPLICAOF redis-primary 6379

# 2. Wait for catch-up, then verify
redis-cli -h valkey-host INFO replication
# master_link_status:up, offsets matching

# 3. Promote Valkey and repoint your app
redis-cli -h valkey-host REPLICAOF NO ONE

Two migration-specific details worth knowing. Valkey 8 added CLIENT CAPA redirect, which lets a replica redirect data-access commands to the primary during an upgrade, smoothing exactly the kind of node-swapping a migration involves. And because RESP is shared, most tooling keeps working throughout, so your risk concentrates in the edge cases: specific module commands and anything relying on behavior that diverged after 7.2.

The decision, in one checklist

If you are evaluating this in late 2026, here is the honest scorecard:

Choose Valkey if:

• You use Redis as a cache, session store, rate limiter, pub/sub broker, or queue on core data structures.
• You are on AWS or GCP managed services. ElastiCache and Memorystore already default to Valkey, and the pricing is lower.
• Your legal or compliance team has AGPL restrictions or wants permissive licensing for embedded or redistributed deployments.
• Pipelined throughput matters to your latency budget.

Stay on Redis if:

• You depend on Redis 8's integrated modules: Time Series, full-text search with relevance ranking, Vector Sets, or Cuckoo/Top-K/T-Digest structures.
• You hold Redis Enterprise licenses and are satisfied with the support.
• Your managed provider is Azure, which still backs Azure Cache for Redis with actual Redis.

Run both if:

• Some workloads need Redis modules while your plain caching layer would benefit from Valkey's licensing and price. Nothing stops a split deployment.

For my own mental model as a backend engineer who mostly meets these systems as caches and session stores: the default answer for new projects in 2026 is Valkey, and the burden of proof is now on the side arguing for Redis. That reverses the burden from 2024, and it happened faster than almost anyone predicted.

What I would watch next

Two things will shape the next twelve months. First, whether valkey-search closes the gap toward full RediSearch parity, because vector search on a BSD-licensed cache is a compelling AI-infrastructure story. Second, whether Redis keeps investing in the AGPL community edition or lets it lag behind Redis Cloud, which would quietly reopen the "is Redis open source" question. The ValkeyConf keynote happening today in Prague should be worth reading either way.

I write about backend engineering, developer tools, and AI infrastructure every week. Subscribe, it's free.

Which one are you running in production, and did the license change push you or did you move for performance? I'm curious how split the readership is on this.

Sources: Redisson's Valkey vs Redis 2026 comparison (July 2026) for the version, license, and module details; the sanj.dev migration guide (March 2026) for benchmarks, the Snap case study, and migration commands; redis.io's own Valkey explainer for the licensing history; valkey.io for release and RDMA details.

Comments

[Dhruv Malaviya]

The AGPLv3 detail is the correction this debate needed, and it's worth pushing one step further: OSI-approved isn't the same as licence-problem-solved. AGPLv3's network clause triggers on users interacting over a network, which is precisely the managed-service case. So Redis being open source again doesn't restore what cloud providers had under BSD , it changes which agreement they need, not whether they need one.

On the numbers, the 40% pipelined gap should drive decisions and the 8% single-threaded one shouldn't. Almost every serious Redis workload pipelines, because round trips dominate. A benchmark showing 8% is measuring a pattern production rarely uses.

The migration risk that isn't in the performance tables is modules. RediSearch, RedisJSON, RedisBloom and RedisTimeSeries are Redis Ltd. products on their own licensing, and Valkey's equivalents are separately developed with different feature sets and different maturity. The wire protocol is compatible and redis-cli works against both, so the connection string is the easy part , the ecosystem around it is the actual project.

Worth asking in the piece: for teams already on ElastiCache the default flipped underneath them, so some are running Valkey without ever having decided to. That's a different conversation from a migration.