Redis vs Valkey 2026: Licensing, Costs, and Cluster Gaps

Use Valkey for new projects. Redis 8 added AGPLv3 in May 2025, making it legitimately open source again — but “too late” is a fair read. By then, Valkey already had AWS, Google Cloud, and Oracle backing it, cost 20–33% less on AWS managed services, and shipped cluster features Redis still doesn’t have. If you need Redis Enterprise, active-active replication, or deeply integrated TimeSeries, Redis is still the right answer. For everything else, the fork won.

Who this is for

Developers starting a new service and choosing a Redis-compatible store, and engineers running Redis OSS 7.2 who are deciding whether to track the fork. If you’re on Redis Enterprise with active-active CRDT replication or Redis Insight Pro — keep reading, but expect a different verdict.

The licensing story

March 2024: BSD becomes SSPL and RSALv2

Redis Ltd. relicensed Redis 7.4 from BSD-3-Clause to a dual model:

RSALv2 (Redis Source Available License v2): permissive for internal use, but prohibits offering Redis as a managed database service to third parties.
SSPLv1: if you deliver Redis as a service, you must open-source your entire service stack — management layers, APIs, orchestration, backups. MongoDB wrote this license. It is not OSI-approved.

Internal use (your app connecting to Redis) is fully allowed under both. The relicensing targeted cloud providers reselling Redis-as-a-service without a commercial agreement — and it hit. AWS, Google Cloud, and Alibaba Cloud forked rather than pay.

Redis 7.2 and earlier stay on BSD-3-Clause permanently. The change is not retroactive.

May 2025: Redis 8.0 adds AGPLv3

Redis 8.0 added a third license option: AGPLv3. This one is OSI-approved. Redis 8 is now tri-licensed: RSALv2, SSPLv1, and AGPLv3.

AGPLv3 requires that derivative works and networked modifications be open-sourced — milder than SSPL, stricter than BSD. For a startup running Redis internally, the practical difference is small.

Redis 8 also merged the Redis Stack modules into core: JSON, TimeSeries, Bloom, RediSearch, and a new vector set type (authored by Salvatore Sanfilippo). That’s the more operationally significant change.

The community read the AGPLv3 addition as reactive. Over the course of 2025, Valkey drew 346 active contributors, maintained a faster release cadence, and had major cloud backing. The dominant sentiment on HN and Reddit: the olive branch arrived after the party had already moved.

Valkey: current state

Valkey forked from Redis 7.2.4 in March 2024, governed by the Linux Foundation, licensed BSD. The backer list — AWS, Google Cloud, Oracle, Alibaba Cloud — is not subtle. Current stable: Valkey 9.1.0 (May 19, 2026).

The 9.x line ships features Redis doesn’t have:

Hash field expiration: per-field TTL inside a hash. Useful for session stores and feature flags with auto-expiry.
Multi-DB in cluster mode: workload isolation without separate instances.
Atomic slot migration: zero-error resharding with no downtime.
CLUSTERSCAN: consistent key scanning across an entire cluster. Redis users working in cluster mode have wanted this for years.

Valkey 9.1 also redesigned IO threading for up to 17% throughput gain over 9.0, cut per-key memory by up to 10%, and added automated TLS certificate reloading.

Feature parity: Redis 8.0 vs Valkey 9.1

Feature	Redis 8.0	Valkey 9.1	Notes
Core types (String, Hash, List, Set, ZSet, Stream)	✅	✅	Full parity
JSON	✅ merged into core	✅ bundled addon	Same query support
Full-text search	✅ RediSearch in core	✅ Valkey Search 1.2	Both support vector, tag, numeric
Vector search	✅ vector sets	✅ Valkey Search 1.2	Different implementations
Time series	✅ in core	⚠️ bundled, not default	Redis 8 ships it natively
Bloom / probabilistic	✅ in core	✅ bundled
Hash field expiration	❌	✅ (9.0+)	Valkey-only
Multi-DB in cluster	❌	✅ (9.0+)	Valkey-only
Atomic slot migration	❌	✅ (9.0+)	Valkey-only
CLUSTERSCAN	❌	✅ (9.1)	Valkey-only
RESP2 / RESP3	✅	✅
Pub/Sub	✅	✅
Lua scripting	✅	✅
RDB/AOF persistence	✅	✅
ACLs	✅	✅ + DB-level in 9.1	Valkey finer-grained
TLS	✅	✅ + auto-reload in 9.1

One hard compatibility fact: Valkey speaks Redis protocol through Redis 7.2. You cannot replicate between Valkey 9.x and Redis 8.x — the codebases diverged. Migrations require export and import, not live replication.

TimeSeries is the one place where Redis 8’s approach is operationally simpler. It ships in the core binary with no extra configuration. Valkey bundles it as an addon that isn’t loaded by default. If you run time-series workloads at scale, that gap has real weight.

Performance

Third-party benchmarks favor Valkey for mixed workloads.

Percona’s 2025 benchmark on AWS r6g.large (2 vCPU, 16 GB RAM) with 1 KB SET operations: Valkey 8.0 reached 1.20 million ops/sec; Redis OSS 7.4 reached 1.11 million ops/sec — an 8% gap. Under mixed read/write traffic on cache.m7g.large: Valkey P99 latency was 1.8 ms versus Redis OSS at 2.3 ms, a 22% improvement.

Redis 8’s own launch materials claim up to 87% faster commands and 2× throughput for read-heavy cache patterns. Those figures are unverified by independent third parties. They reflect Redis 8’s module-merged architecture on a specific workload. Treat them as directional until an independent benchmark arrives.

Memory efficiency also moved in Valkey’s direction. Valkey 8.1’s hash table redesign reduced memory footprint by over 20% for typical key-value workloads. On AWS, layering that on top of pricing changes produces roughly 36% cumulative savings versus Redis OSS 7.2.

Cloud and hosting

AWS

Valkey is GA across ElastiCache, ElastiCache Serverless, and MemoryDB in all regions since October 2024.

Service	Valkey saving vs Redis OSS
ElastiCache Serverless	33% cheaper
Node-based ElastiCache	20% cheaper
MemoryDB	30% cheaper

AWS endorsing Valkey this explicitly is also a strong signal about long-term support trajectory. Azure, for what it’s worth, still partners with Redis Ltd. and doesn’t offer a Valkey-native managed service — relevant if you’re locked into Azure and want parity.

Upstash

Upstash offers a Redis/Valkey-compatible managed service on a pay-per-request model: $0.20 per 100K requests plus $0.25/GB storage. It scales to zero, has a free tier, and the HTTP REST API works from Cloudflare Workers, Vercel Edge, and other runtimes that don’t support persistent TCP connections.

Best fit: serverless workloads, edge functions, or early-stage apps where connection pooling overhead is a genuine pain. At 10M+ requests/month, ElastiCache becomes more economical.

Render

Render defaults to Valkey 8 for all new Key Value instances since late 2024. Existing Redis 6.2.14 instances continue running — no forced migration. The keyvalue and redis service types in render.yaml both provision Valkey now. Render is the lowest-friction path if you’re already on the platform.

Railway

Railway offers a Valkey template at $1/month. Unlike Render, it’s a containerized deployment you manage — not a fully managed service. Useful if you want Valkey alongside other Railway services and are comfortable owning the container.

Migrating from Redis to Valkey: Node.js

Three options in order of friction:

Option A: Change the connection string (right choice for most teams)

On ioredis 5.3+, core operations need no code changes:

# Before
REDIS_URL=redis://your-redis-host:6379

# After
REDIS_URL=redis://your-valkey-host:6379

import Redis from 'ioredis'
const client = new Redis(process.env.REDIS_URL)

Test HGETALL, HELLO, and CLIENT INFO if you use RESP3-aware features or call HELLO directly. Transactions, pub/sub, sorted sets: compatible.

If you’re on ioredis below 5.3, upgrade first.

Option B: Migrate to Valkey GLIDE

GLIDE is the official Valkey Node.js client with a Rust core. Higher throughput than ioredis on batch-heavy workloads — but the API changed significantly, and it’s not a drop-in replacement:

Operation	ioredis	GLIDE
Install	`npm i ioredis`	`npm i @valkey/valkey-glide`
Connect	`new Redis(url)`	`GlideClient.createClient({addresses:[...]})`
DEL multiple	`del('k1','k2')`	`del(['k1','k2'])`
HSET	`hset('h','k','v')`	`hset('h', {k:'v'})`
ZADD	`zadd('z', 1, 'a')`	`zadd('z', [{score:1, member:'a'}])`
SETEX	`setex('k',5,'v')`	`set('k','v', {expiry:{type:TimeUnit.Seconds, count:5}})`
Transactions	`redis.multi().exec()`	`new Transaction()` class
Lua scripts	`eval()` / `evalsha()`	`Script` class + `invokeScript()`
`exists` return	Integer (0/1)	Boolean

Only worth the migration cost for throughput-critical code paths: high-volume pub/sub, batch pipelines.

Option C: @upstash/redis (zero friction if you’re already heading to Upstash)

Upstash’s SDK abstracts the underlying engine. Change the endpoint, keep the code:

import { Redis } from '@upstash/redis'
const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL,
  token: process.env.UPSTASH_REDIS_REST_TOKEN,
})

No other changes needed.

Verdict

New projects: use Valkey. The license is BSD under Linux Foundation governance (no relicensing risk), it’s cheaper on every major managed cloud, its cluster tooling is ahead of Redis 8, and the ioredis migration is a connection string change.

Existing Redis OSS 7.2 deployments: migrate at your next upgrade window. The ioredis path (Option A) gets you there with minimal surface area.

Use Redis 8 if: you need Redis Enterprise — commercial support, multi-zone active-active replication, Redis Insight Pro. Or if TimeSeries is central enough to your architecture that loading it as a separate Valkey addon would cause real operational friction.

Avoid Redis 8 if: your legal or compliance team scrutinizes licenses. AGPLv3’s network-service copyleft clause — requiring open-sourcing networked modifications — can complicate internal reviews even for purely internal deployments. BSD has no such clause.

The “too late” community reaction wasn’t sentiment alone. Valkey had already moved. Redis 8’s AGPLv3 makes it a legitimate choice again; the economics and momentum don’t change.

If you’re rebuilding your backend stack alongside the cache layer, our Supabase vs Firebase comparison covers the managed database trade-offs for the same audience. If the Node.js migration section sent you down the runtime rabbit hole, Bun vs Node walks through the runtime decision and its compatibility implications.