Valkey vs Redis in 2026: When to Pick the Fork
The April 2024 Valkey fork changed the decision from two-way to three-way. Here is when to pick which.
Redis 8.10 vs Valkey 9.1: side-by-side spec table
| Feature | Redis 8.10 | Valkey 9.1 |
|---|---|---|
| License | RSALv2 / SSPLv1 / AGPLv3 (tri) | BSD-3-Clause |
| OSI open source | Yes (under AGPLv3 only) | Yes (BSD is OSI-approved) |
| RESP protocol | Yes | Yes (drop-in compatible) |
| Vector / similarity search | Yes, vector sets (VADD/VSIM) in core (Redis 8.0, May 2025) | Yes, via valkey-search module (GA Jul 2025); not a core data type |
| Hash field TTL | Yes (Redis 8.0) | Yes (Valkey 9.0, Oct 2025) |
| Multi-threaded I/O | Yes (I/O threads) | Yes (redesigned in 8.0, 30-35% gain) |
| Memory efficiency at scale | Baseline | ~28% lower at 50M sorted-set entries (Momento, independent) |
| Backed by | Redis Inc | Linux Foundation (AWS, Google, Oracle, Ericsson) |
| AWS managed | Available (ElastiCache Redis OSS) | Default for new AWS ElastiCache deployments |
| GCP managed | Memorystore for Redis (legacy) | Memorystore for Valkey (default) |
| Aiven managed | Aiven for Redis (legacy) | Aiven for Valkey (primary, ~20% cost savings) |
| Current version | 8.10.x | 9.1.x |
Sources: Redis 8.0 GA blog, valkey.io, Momento benchmark
Pick Valkey if...
SSPL or AGPLv3 blocks your licensing approval
If your legal or procurement team has flagged Redis 7.4+ as non-compliant (SSPL or RSALv2 concerns), Valkey's BSD-3 license is the clean path. No copyleft, no managed-service restrictions, no OSI grey area.
You are on AWS ElastiCache or Google Memorystore already
Both clouds default to Valkey for new deployments since 2024-2025. If you created a new cluster recently, you may already be on Valkey. Check your cluster engine version in the console.
Memory efficiency at scale matters
Valkey 8.1 shows ~28% lower memory at 50M sorted-set entries vs Redis 8.0 in the Momento independent benchmark. At hyperscale, that is a real cost difference. Source: Momento (independent, AWS c8g.2xlarge Graviton4).
You want OSI-approved permissive open source with no commercial entity gatekeeping
Valkey is governed by the Linux Foundation, not a single commercial entity. The BSD license has no strings. Redis Inc's RSALv2 and SSPL explicitly restrict how you can use Redis commercially.
You do not need Redis's core vector set data type
Valkey 9.0 (Oct 2025) added hash field TTL (HEXPIRE), and vector similarity search is available via the valkey-search module (GA Jul 2025). If you do not need Redis's specific VADD/VSIM core data type, Redis Stack modules, or vendor-supported Redis Cloud SLAs, Valkey covers your workload. Valkey is fully compatible with the Redis 7.2 command set.
Pick Redis 8.0 if...
You want vector search built into the core data model
Vector sets (VADD, VSIM, VDIM commands, HNSW algorithm) ship inside Redis 8.0 core (May 2025). Valkey delivers vector similarity search too, but through the separate valkey-search module (GA July 2025; hybrid full-text added with Valkey 9.1). If you prefer vector similarity as a first-class core data type rather than a loadable module, Redis 8.0 is the cleaner fit.
You depend on Redis Stack modules (RedisJSON, RediSearch, RedisGraph)
Redis Stack modules are Redis Inc proprietary and do not run on Valkey. Valkey has its own module ecosystem (valkey-search for search/vector, valkey-bloom, valkey-json), but RedisJSON / RediSearch behaviour is not identical. If your workload is tightly coupled to Redis Stack module APIs, migrating to Valkey requires porting to the Valkey equivalents first.
You want new core features upstream-first
Redis Inc shipped vector sets and hash field TTL in Redis 8.0 (May 2025); Valkey reached hash field TTL in core with 9.0 (Oct 2025). If you want to be on the earliest release of new core capabilities, Redis tends to land them first.
You have commercial Redis Cloud SLAs
Redis Inc provides enterprise support contracts and Redis Cloud SLAs. If you have a commercial Redis Inc agreement, staying on Redis 8.0 preserves that relationship. Valkey has managed providers (Aiven, AWS, GCP) but no Redis Inc SLA.
Migration playbook: Redis to Valkey
Aiven migrated 15,000 servers from Redis to Valkey in 3 months (May-August 2024). Here is the general playbook.
Verify command compatibility
Valkey is drop-in for Redis 7.2.4 baseline. Most Redis 7.4-compatible commands work too. Scan your codebase for Redis 8.0-specific commands (vector sets, hash field TTL) before migrating. Source: valkey.io compatibility docs.
Identify Redis Stack module dependencies
RedisJSON, RediSearch, RedisGraph do not run on Valkey. If your app uses these, migration requires replacing them first. Valkey ecosystem alternatives are emerging but check readiness for your use case.
Stand up Valkey alongside Redis
Run both in parallel. Configure your application to dual-write to both stores for one to two weeks. This validates data compatibility and gives you a rollback path without downtime.
Cutover and monitor
Flip reads to Valkey. Monitor hit rates, latency, and error rates. Valkey's RESP protocol compatibility means most clients (ioredis, redis-py, Jedis) work without code changes. Keep Redis warm for one week post-cutover before decommissioning.
Aiven migration reference: Valkey blog: 2024 year of Valkey
Expect one quarter of CI/staging/prod cutover work for a non-trivial migration. The CI cost compounds. CI/CD Cost Calculator →
Verdict: 2026
For most 2026 commercial shops with license sensitivity, Valkey is the lower-risk pick. Redis 8.0 is the higher-feature pick. If you are on AWS ElastiCache or Google Memorystore and created a new cluster recently, you may already be on Valkey. Check before migrating. Cache stack cost is one node in the broader tech stack decision. Tech Stack Cost →
Valkey vs Redis: FAQ
Should I choose Valkey or Redis in 2026?
Pick Valkey if license matters (its BSD-3-Clause license avoids the SSPL/RSALv2/AGPLv3 restrictions of Redis 7.4+), if you are on AWS ElastiCache or Google Memorystore managed (both default new deployments to Valkey since 2024-2025), or if you want OSI-permissive open source with no single commercial gatekeeper. Pick Redis 8.0 if you need its core vector set data type (VADD/VSIM), Redis Stack modules (RedisJSON, RediSearch), or commercial Redis Cloud SLAs. For most 2026 commercial shops with license sensitivity, Valkey is the lower-risk pick; Redis is the higher-feature pick.
Is Valkey compatible with Redis?
Yes. Valkey is a drop-in replacement for the Redis 7.2.4 baseline and speaks the same RESP protocol, and it is fully compatible with the Redis 7.2 command set. Most Redis clients (ioredis, redis-py, Jedis) work against Valkey without code changes. The gap is Redis 8.0-specific features: core vector sets and, historically, hash field TTL. Scan your codebase for those before migrating.
What is the license difference between Valkey and Redis?
Redis Inc ships Redis under a tri-license (RSALv2 / SSPLv1 / AGPLv3); it is OSI open source only under the AGPLv3 option. Valkey is licensed BSD-3-Clause, which is OSI-approved and permissive with no copyleft or managed-service restrictions. Valkey is governed by the Linux Foundation (backed by AWS, Google, Oracle, Ericsson) rather than a single commercial entity, which is why AWS and Google made it the default engine for new managed deployments.
Does Valkey support vector search?
Yes, through the valkey-search module (GA July 2025), which provides HNSW vector similarity search and secondary indexing; hybrid full-text search and aggregations were added with Valkey 9.1. Redis delivers vector search too, but as a core data type: vector sets (VADD, VSIM, HNSW) shipped inside Redis 8.0 core in May 2025. The practical difference is core data type (Redis) versus a loadable module (Valkey), not presence versus absence.
How do I migrate from Redis to Valkey?
The general playbook is four steps: (1) verify command compatibility, scanning for Redis 8.0-specific commands (vector sets, hash field TTL); (2) identify Redis Stack module dependencies (RedisJSON, RediSearch, RedisGraph do not run on Valkey and must be replaced first); (3) stand up Valkey alongside Redis and dual-write to both for one to two weeks to validate compatibility and keep a rollback path; (4) cut reads over to Valkey and monitor hit rate, latency, and errors, keeping Redis warm for a week before decommissioning. Expect roughly one quarter of CI/staging/prod cutover work for a non-trivial migration.