Valkey vs Redis: Licensing, Performance and Migration
Chat2DB TeamIn March 2024 Redis Ltd. changed the licence of Redis from the permissive BSD to a dual RSALv2 / SSPLv1 model. Within a week the Linux Foundation announced Valkey, a fork of Redis 7.2.4 backed by AWS, Google Cloud, Oracle, Ericsson and Snap. Two years on, both projects are healthy, both are widely deployed, and the practical question for a team in 2026 is which one to run.
This article covers what the licence change actually restricts, how the two have diverged technically, what the performance difference looks like, and how to migrate.
The licensing situation
Redis 7.4 – 7.x shipped under RSALv2 (Redis Source Available License) or SSPLv1, at the user's choice. Neither is an OSI-approved open source licence. In practice RSALv2 forbids offering Redis as a managed commercial service; SSPLv1 requires anyone offering it as a service to release the entire service stack under SSPL.
Redis 8, released in 2025, added AGPLv3 as a third option. AGPL is OSI-approved, which resolved much of the objection — but AGPL has its own consequence: if you modify Redis and expose it over a network, you must publish your modifications. Many corporate legal departments treat AGPL as a blocker regardless of the details.
Valkey is BSD-3-Clause, exactly what Redis was before the change, under Linux Foundation governance.
For the overwhelming majority of users — running Redis internally as a cache or queue, unmodified — none of these licences restrict anything. The change matters if you are:
- A cloud or SaaS provider offering Redis-compatible service.
- Embedding Redis in a product you distribute.
- Working under a policy that prohibits non-OSI or copyleft licences.
If none of those apply, choose on technical merit, not licence.
What Valkey changed
Valkey started identical to Redis 7.2.4 and has since shipped substantial engineering, much of it performance work driven by AWS.
Multi-threaded I/O and async command execution
Redis's defining constraint was its single-threaded command loop. Valkey 8.0 rebuilt the I/O threading model so that reading, parsing and writing happen across threads while command execution stays serialised for correctness. Combined with the asynchronous I/O path, the published benchmarks show substantially higher throughput on multi-core machines — AWS reported around 1.2 million requests per second per node on comparable hardware, roughly triple Valkey 7.2.
Enable it:
# valkey.conf
io-threads 8Redis 8 also improved its threading, narrowing the gap, but Valkey's rework is more thorough.
Memory efficiency
Valkey 8.1 restructured the key storage layout to embed keys and metadata directly in the dictionary entry, removing pointer indirection and per-key allocator overhead. The reported saving is roughly 20 bytes per key — meaningful when you hold hundreds of millions of small keys, where per-key overhead can be a third of total memory.
Check what your workload actually uses:
valkey-cli INFO memory
valkey-cli MEMORY USAGE mykey
valkey-cli --bigkeys
valkey-cli MEMORY DOCTORCluster improvements
Valkey added atomic slot migration, which moves hash slots between nodes in a single atomic step rather than the key-by-key migration Redis uses. Resharding a large cluster becomes markedly less disruptive. It also added automatic failover improvements and better replica handling under partial partitions.
RDMA and dual-channel replication
Valkey supports RDMA transport for very low-latency networks, and dual-channel replication, which separates the full sync snapshot stream from the replication backlog so a full sync no longer risks buffer overrun on the primary.
What Redis changed
Redis has not stood still, and Redis 8 is a substantial release.
- Vector sets — a native data type for vector similarity search, in the core rather than a module.
- Modules in core. RedisJSON, RediSearch (query engine), time series and probabilistic data structures ship with the open source distribution instead of being separate, differently licensed modules. This is the largest functional gap versus Valkey: if you use
FT.SEARCHorJSON.SET, Redis 8 gives you them out of the box. - Performance work across the command dispatch path and replication.
- Redis Flex, which tiers less-used data to SSD to reduce RAM cost.
Valkey's equivalents come from modules — the community valkey-search, valkey-json and valkey-bloom modules cover the main cases, and they are BSD-licensed, but they are separate components to install and operate.
Compatibility
This is the reassuring part. Valkey maintains protocol and command compatibility with Redis 7.2:
- Same RESP2 and RESP3 wire protocol.
- Same commands, same semantics, same error messages.
- RDB and AOF files are interchangeable in both directions for the 7.2 format.
- Every Redis client library works unchanged — Jedis, Lettuce, redis-py, node-redis, go-redis, StackExchange.Redis.
redis-clitalks to Valkey andvalkey-clitalks to Redis.
# Point an existing client at Valkey; nothing changes
redis-cli -h valkey.internal -p 6379 INFO server
# server_name:valkey
# valkey_version:8.1.1The compatibility promise is versioned at Redis 7.2. Features added to Redis 8 — vector sets, the bundled search and JSON modules — are not in Valkey core and will not be. If you depend on those, that is the decision.
Performance in practice
Treat vendor benchmarks with the scepticism they deserve, and measure your own workload. Both ship a benchmark tool:
# Baseline: mixed GET/SET, 50 connections, pipelining 16
valkey-benchmark -h 127.0.0.1 -p 6379 -t get,set -n 1000000 -c 50 -P 16 -q
# Realistic value sizes matter a lot
valkey-benchmark -t set -n 500000 -d 512 -c 100 -q
# Latency, which is usually what you actually care about
valkey-cli --latency-history -i 5
valkey-cli --latency-distWhat the numbers generally show in 2026:
- Single-threaded, small values: Redis and Valkey are within noise of each other.
- Many cores, high connection counts: Valkey's I/O threading gives it a real throughput advantage.
- Memory per key at high key counts: Valkey uses less, by roughly 10–20% on small-key workloads.
- Latency percentiles: comparable; both are dominated by network round trip in real deployments.
The honest summary: for a typical application cache at a few thousand operations per second, the difference is invisible. At very high throughput on large instances, Valkey's threading work shows.
Migrating from Redis to Valkey
Because the RDB format and protocol match, migration is mostly an operational exercise.
Option 1: replica promotion (near-zero downtime).
# 1. Start Valkey and make it a replica of the Redis primary
valkey-server --port 6380 --replicaof redis-primary 6379
# 2. Wait for the initial sync to finish
valkey-cli -p 6380 INFO replication
# master_link_status:up
# master_sync_in_progress:0
# 3. Promote it
valkey-cli -p 6380 REPLICAOF NO ONE
# 4. Repoint the application, then decommission RedisOption 2: RDB copy (accepts a gap).
redis-cli BGSAVE
redis-cli INFO persistence | grep rdb_bgsave_in_progress # wait for 0
scp /var/lib/redis/dump.rdb valkey-host:/var/lib/valkey/dump.rdb
ssh valkey-host 'chown valkey:valkey /var/lib/valkey/dump.rdb && systemctl start valkey'Option 3: live sync with a tool. riot or redis-shake replicate continuously, which suits large datasets where a long full sync is risky.
Checklist before cutting over:
- Audit for Redis 8-only features. Grep your codebase for
FT.,JSON.,TS.,VADD/VSIMcommands. If they appear, you need the Valkey modules or you stay on Redis. - Confirm your managed provider. AWS ElastiCache and MemoryDB offer Valkey (at a lower price point than their Redis OSS offering); Google Cloud Memorystore offers both.
- Update monitoring. Metric names are compatible, but
INFO serverreportsvalkey_versionrather thanredis_version— dashboards and alerts keying on that field will break. - Update config file paths and service names.
/etc/redis/redis.confbecomes/etc/valkey/valkey.conf; the daemon user changes. - Test failover in staging, particularly if you use Sentinel or Cluster.
Rollback is symmetric — Valkey's RDB can be loaded by Redis 7.2+ — which makes this an unusually low-risk migration.
Choosing
Choose Valkey when:
- You want a permissive BSD licence and vendor-neutral Linux Foundation governance.
- You run at high throughput on multi-core hardware and want the I/O threading gains.
- You hold very large numbers of small keys and care about memory per key.
- Your managed provider prices it lower — on AWS this is often the deciding factor.
Choose Redis when:
- You use RediSearch, RedisJSON, time series or vector sets and want them supported in one product.
- Redis Enterprise features, support contracts or Redis Cloud are part of your plan.
- AGPLv3 is acceptable to your organisation and you value having the original maintainers behind the code.
Either is fine for the common case: an application cache, a session store, a rate limiter, a job queue. Both are actively developed, both are production-grade, and the migration path between them is short in both directions.
Where the cache sits in the wider picture
Whichever you run, the cache is usually in front of a relational database, and most cache problems turn out to be database problems in disguise — a missing index, an unbounded query, a hot key that mirrors a hot row. Being able to inspect the underlying Postgres or MySQL alongside the cache shortens that investigation; Chat2DB (opens in a new tab) connects to those and 20+ other databases, with a web version at app.chat2db.ai (opens in a new tab).
Summary
Valkey is the BSD-licensed, Linux Foundation fork of Redis 7.2.4, with real engineering behind it: multi-threaded I/O, lower per-key memory, atomic slot migration and dual-channel replication. Redis responded with AGPLv3 as a licence option and Redis 8, which folds search, JSON, time series and vector sets into the core product. They remain wire-compatible at the Redis 7.2 command set, so migration is straightforward and reversible. Decide on licence policy first, then on whether you need Redis 8's bundled modules; if neither constrains you, pick on price and operational fit.
