Valkey in 2026: What Happened When Redis Changed Its License

In March 2024, Redis Ltd. announced that Redis — for fifteen years the default in-memory cache for nearly every web stack — would no longer be released under the BSD license. Future versions would fall under the Server Side Public License (SSPL) and the Redis Source Available License (RSALv2). Both licenses prohibit cloud providers from offering Redis as a managed service without buying a commercial license from Redis Ltd.

The target was obvious: AWS, Google Cloud, and Azure had been selling managed Redis for years, paying nothing upstream. Redis Ltd. wanted them to pay.

The move worked financially. The collateral damage was the community.

What Is Valkey

Within a week of the license announcement, contributors from AWS, Google, Oracle, Ericsson, and others forked Redis 7.2.4 (the last BSD-licensed version) and donated the fork to the Linux Foundation. They named it Valkey.

Valkey 7.2.5 shipped in April 2024, functionally identical to Redis 7.2.4 plus the fixes accumulated since. Valkey 8.0 arrived in September 2024, adding new features the Redis 8.0 announcement had previewed, including vector set support and hash field expiration. Valkey 8.1 followed in early 2025.

By mid-2026, Valkey is the default in-memory store for new projects at most cloud providers. AWS ElastiCache and MemoryDB now default to Valkey. Google Memorystore for Redis pivoted to Valkey for new clusters. Upstash supports both, with Valkey as the recommended option. Render, Railway, and most PaaS providers followed suit.

The question “should I use Redis or Valkey?” is still a real one, but for many teams the answer has already been made by their cloud provider.

Compatibility: The Short Version

Valkey is a drop-in replacement for Redis up to version 7.2. The protocol is identical. Every Redis client library — ioredis, redis-py, Jedis, StackExchange.Redis, go-redis — works with Valkey without any changes to your connection code. The only thing that changes is the server you’re connecting to.

# This works against both Redis and Valkey — no changes needed
import redis

client = redis.Redis(host="your-valkey-host", port=6379, db=0)
client.set("key", "value", ex=3600)
val = client.get("key")

If you’re on Redis 6.x or 7.x and self-hosting, migration is a backup-and-restore operation. Most teams do it during a maintenance window or use replication to cut over with no downtime.

If you’re on a managed service, the migration path depends on your provider. AWS ElastiCache lets you in-place upgrade existing Redis 7.1 clusters to Valkey. Google Memorystore requires creating a new Valkey instance and migrating data.

Feature Divergence: 2025 and 2026

The versions after 7.2.4 are where Redis and Valkey have started to diverge.

Redis 8.0 and later are source-available under RSALv2. They added vector similarity search as a first-class type and hash field expiration without TTL on the entire key. Redis Ltd. also removed the need for the RediSearch and RedisJSON modules by folding their functionality into the core binary.

Valkey matched most of these in its own releases, but independently:

Feature	Redis 8.x	Valkey 8.x
Vector sets	Yes (Redis Vector Sets)	Yes (added in 8.0)
Hash field expiry	Yes	Yes
JSON type (native)	Yes	No (use RedisJSON-compatible module)
Full-text search (native)	Yes	No (use external module or Manticoresearch)
RESP3 protocol	Yes	Yes
Cluster sharding improvements	Yes	Yes
License	RSALv2 / SSPL	BSD 3-Clause

The biggest practical difference is JSON and full-text search. Redis 8 ships with both natively; Valkey does not. If your application depends on RedisJSON or RediSearch heavily, you have two options: run the open-source module builds alongside Valkey, or stay on Redis.

For the vast majority of uses — caching, session storage, pub/sub, rate limiting, job queues — the feature sets are equivalent and the license is the only meaningful difference.

Performance: Where Valkey Has Pulled Ahead

The Valkey project made a deliberate architectural choice in early 2025: adding a multi-threaded I/O model for network handling, similar to what KeyDB (another Redis fork) had pioneered. Redis has had multi-threaded I/O since Redis 6 but kept command processing single-threaded.

Valkey 8.1 added “threaded I/O with per-slot locking” that allows parallel command execution on non-overlapping keyspaces in cluster mode. On high-throughput workloads with many concurrent connections, Valkey 8.1 benchmarks show 20-35% higher throughput than Redis 8.0 at equivalent hardware.

Those numbers are from the Valkey project’s own benchmarks and should be taken with appropriate skepticism. Real production workloads vary significantly. But the architectural direction is clear: Valkey is optimizing for throughput at scale, which is the direction high-volume users wanted Redis to go.

Should You Migrate Existing Redis Installations?

The practical answer depends on two things: where you’re running, and what features you’re using.

You’re on a managed service (ElastiCache, Memorystore, Upstash, Aiven): Check whether your provider has already moved to Valkey or offers it. If they do, migration is low-risk — the API is identical, and the operational burden shifts to the provider. Do it when you have a maintenance window.

You’re self-hosting Redis on VMs or containers: If you’re on Redis 7.2 or earlier, you have a genuinely free choice. Valkey is BSD-licensed and actively maintained by a large consortium. Redis 8+ requires complying with RSALv2, which prohibits offering it as a service to third parties. For internal use, RSALv2 is permissive enough that it doesn’t matter. For agencies or platform teams managing Redis on behalf of clients, RSALv2 starts to matter.

You’re using Redis Stack (JSON, Search, Graph): The Graph module was deprecated by Redis Ltd. anyway. For JSON and Search, evaluate whether the module ecosystem for Valkey meets your needs, or whether staying on Redis (under RSALv2 for internal use) is less disruptive.

You’re building something new: Start with Valkey unless you have a specific reason not to. The managed-service ecosystem now defaults to it, the community momentum is behind it, and you won’t be making a licensing decision you have to revisit later.

The Ecosystem Settled Quickly

What’s notable about the Redis-Valkey split compared to, say, the OpenSSL vs LibreSSL fork or the OpenOffice vs LibreOffice split, is how fast the major players committed.

Within six months of the fork, AWS, Google, and Azure had all announced Valkey support in their managed services. The major Redis client maintainers (ioredis, redis-py, Jedis) all added Valkey compatibility notes to their docs. The GitHub star count for Valkey passed 20,000 within its first year.

Redis Ltd. retained its commercial customer base and continued shipping Redis 8.x with the new features that enterprise buyers wanted. Both projects are active and maintained.

The lesson for open-source observers: when a major infrastructure project changes its license in a way that affects cloud providers, the providers will fork it. And when the Linux Foundation backs the fork, the ecosystem follows. The same pattern played out with Elasticsearch/OpenSearch in 2021. Redis/Valkey is just the most recent data point.

Practical Migration Checklist

For teams running self-hosted Redis:

# 1. Check your Redis version
redis-cli INFO server | grep redis_version

# 2. Export current data (RDB snapshot)
redis-cli BGSAVE
# Wait for it to finish, then copy dump.rdb

# 3. Install Valkey (example: Ubuntu)
curl -fsSL https://packages.valkey.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/valkey-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/valkey-archive-keyring.gpg] https://packages.valkey.io/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/valkey.list
sudo apt update && sudo apt install valkey

# 4. Copy dump.rdb to Valkey's data directory
# 5. Start Valkey, verify keys loaded
valkey-cli DBSIZE

For cloud migrations: use your provider’s documentation — each has a different migration path, and following it avoids manual data transfer.

The RESP protocol, data structures, and commands are the same. Your application won’t know the difference unless you check the SERVER INFO output. That’s the whole point.