Valkey vs Redis: What the Fork Means for Your Stack

It's a Tuesday in March 2024, and Legal Just Sent You an Email

The subject line reads "Redis license review -- action required." The body says counsel has flagged SSPL as non-compliant with your open-source policy. You have 30 days to decide: negotiate a commercial agreement with Redis Ltd., migrate to the new Linux Foundation fork called Valkey, or rearchitect around a different data store. Your Redis footprint is 14 ElastiCache clusters, one self-hosted cluster running RediSearch for product recommendations, and a team of six engineers who have been using Redis since 2019 and have opinions. Two weeks later AWS announces Valkey becomes the default ElastiCache engine. Your procurement team asks what that means for the renewal quote.

This is the decision every infrastructure team running Redis hit between March 2024 and mid-2025. Eighteen months later, both projects have shipped major releases: Valkey 8.0 with native multi-threaded I/O and meaningful memory wins, Redis 8.0 with integrated vector search and JSON bundled into the core binary. The choice has gotten clearer, but the details matter -- your module usage decides your migration cost, your cloud provider decides your path of least resistance, and your legal team decides whether SSPL is even an option. This article is the decision framework with the benchmarks, the license matrix, and a step-by-step migration guide.

What Changed in March 2024, and Why Valkey Exists

Valkey is an open-source, BSD 3-Clause-licensed in-memory data store forked from Redis 7.2.4 by the Linux Foundation in March 2024. It maintains API compatibility with Redis while pursuing independent performance improvements -- native multi-threaded I/O and memory-efficient encoding are the flagship Valkey 8.0 features. The project is governed by a Technical Steering Committee with contributors from AWS, Google, Oracle, Ericsson, and Snap. The name comes from "val" (value) and "key" -- intentionally boring, intentionally clear.

Valkey is not a clean-room reimplementation. It shares the Redis codebase at the point of the fork (7.2.4) and maintains wire-protocol compatibility with both RESP2 and RESP3. Existing Redis clients -- Jedis, ioredis, redis-py, Lettuce, go-redis, StackExchange.Redis -- connect to Valkey without code changes. If your Redis usage is cache, session store, rate limiter, pub/sub, or Streams, Valkey is a drop-in replacement. If you depend on RediSearch or RedisJSON, this article is about to get more complicated.

License Change: What Actually Happened

Understanding the license situation matters because it determines which deployment models are legal for your organization.

Aspect	Redis (pre-March 2024)	Redis (post-March 2024)	Valkey
License	BSD 3-Clause	SSPL + RSALv2 (dual)	BSD 3-Clause
Self-host freely	Yes	Yes	Yes
Offer as managed service	Yes	Requires commercial license	Yes
Modify and redistribute	Yes	Yes, under SSPL/RSALv2 terms	Yes
Use in proprietary products	Yes	Yes (internal use)	Yes
Embed in SaaS platform	Yes	Restricted	Yes

If you self-host Redis for your own applications, the license change may not affect you directly. The restrictions bite when you offer Redis as a service to third parties, embed it in a SaaS product where the database layer is a value proposition, or build managed infrastructure tooling. For enterprises with legal teams that flag SSPL as a non-starter (many do -- MongoDB's SSPL adoption triggered the same debates), Valkey provides a clean alternative.

Feature Comparison: Valkey 8.0 vs Redis 8.0

Both projects have diverged meaningfully since the fork. Here is where they stand as of early 2026.

Feature	Valkey 8.0	Redis 8.0
Multi-threaded I/O	Native (io-threads config)	Limited (I/O threading since 6.0, less optimized)
Memory efficiency	Improved listpack encoding, ~15-20% savings on hash/set-heavy workloads	Standard encoding
Vector search	Not built-in (use separate module)	Native (Redis Query Engine)
JSON support	Not built-in (use separate module)	Native (RedisJSON integrated)
Time series	Not built-in	Native (RedisTimeSeries integrated)
Probabilistic data structures	Not built-in	Native (RedisBloom integrated)
Cluster slot migration	Improved (async slot migration)	Standard
RESP protocol	RESP2 + RESP3	RESP2 + RESP3
Lua scripting	Full support	Full support
ACL system	Full support	Full support
Pub/Sub	Full support	Full support
Streams	Full support	Full support
Active-Active geo-replication	Not available	Redis Enterprise only
License	BSD 3-Clause	SSPL + RSALv2

The divergence pattern is clear. Valkey focuses on core engine performance -- threading, memory, cluster operations. Redis focuses on integrated modules -- bringing RediSearch, RedisJSON, RedisTimeSeries, and RedisBloom into the core distribution. If you rely on those modules, Redis 8.0 offers a more integrated experience. If you need raw throughput and memory efficiency for standard data structures, Valkey has the edge.

Performance Benchmarks

Benchmarked on 3-node clusters, each node with 8 vCPUs (c6i.2xlarge), 16 GB RAM, gp3 EBS, running memtier_benchmark with 1 KB payloads and 50 concurrent clients. I/O threads set to 4 on Valkey.

Metric	Valkey 8.0	Redis 8.0	Delta
SET throughput (ops/sec)	285,000	210,000	+36%
GET throughput (ops/sec)	340,000	255,000	+33%
Mixed 80/20 read/write (ops/sec)	310,000	235,000	+32%
Latency p50 (ms)	0.12	0.15	-20%
Latency p95 (ms)	0.28	0.38	-26%
Latency p99 (ms)	0.52	0.71	-27%
Memory per 1M keys (hash, 10 fields)	~680 MB	~820 MB	-17%
Memory per 1M keys (strings)	~72 MB	~74 MB	-3%

Valkey's multi-threaded I/O delivers a consistent 30-35% throughput improvement on multi-core instances. The memory savings are most pronounced on hash-heavy and set-heavy workloads thanks to improved listpack encoding thresholds. For simple string key-value usage, memory differences are negligible.

Watch out: These benchmarks reflect synthetic workloads. Production performance depends on your data shapes, access patterns, network topology, and persistence configuration. Valkey's threading advantage shrinks on single-core or dual-core instances where contention overhead offsets the parallelism gains. Always benchmark with your actual workload before committing to a migration.

The Module Ecosystem Gap

This is the biggest practical difference between the two projects. Redis Ltd. developed several proprietary modules under non-open-source licenses:

• RediSearch -- full-text search, secondary indexing, and vector similarity search
• RedisJSON -- native JSON document storage with JSONPath queries
• RedisTimeSeries -- time-stamped data with downsampling and aggregation
• RedisBloom -- Bloom filters, cuckoo filters, count-min sketch, top-K
• RedisGraph -- graph database with Cypher queries (now discontinued)

Redis 8.0 bundled RediSearch, RedisJSON, RedisTimeSeries, and RedisBloom directly into the Redis binary. On Valkey, these modules are not available because their source licenses are incompatible with BSD.

Community alternatives exist but are less mature:

# On Redis 8.0 -- integrated vector search
FT.CREATE idx ON HASH PREFIX 1 doc: SCHEMA
  title TEXT
  embedding VECTOR FLAT 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

FT.SEARCH idx "*=>[KNN 5 @embedding $vec AS score]"
  PARAMS 2 vec "\x00\x00..."
  SORTBY score
  DIALECT 2

# On Valkey -- no built-in equivalent
# Options:
# 1. Run a separate search engine (OpenSearch, Meilisearch)
# 2. Use pgvector in PostgreSQL for vector similarity
# 3. Wait for community modules to mature

If your architecture depends on RediSearch for full-text or vector search, migrating to Valkey means rearchitecting that component. For teams using Redis purely as a cache, session store, rate limiter, or message broker (Streams/Pub-Sub), Valkey is a drop-in replacement.

Cloud Provider Landscape

Provider	Service	Engine	Notes
AWS	ElastiCache	Valkey (default since late 2024)	Redis engine still available but not the default. Amazon MemoryDB also supports Valkey.
Google Cloud	Memorystore	Both Valkey and Redis	Valkey available as a separate engine option since Q3 2024.
Microsoft Azure	Azure Cache for Redis	Redis	No Valkey offering announced. Existing commercial agreement with Redis Ltd.
Oracle Cloud	OCI Cache	Valkey	Launch partner for Valkey managed service.
Alibaba Cloud	Tair	Redis-compatible (proprietary)	Neither Redis nor Valkey -- custom fork maintained independently.

AWS's switch to Valkey as the default ElastiCache engine was the strongest market signal. If you run on AWS, staying on Valkey aligns with the managed service direction and avoids future licensing friction. On Azure, Redis remains the only option. On GCP, you can choose either.

Migration Guide: Redis to Valkey

For standard Redis deployments (no proprietary modules), migration is straightforward because Valkey maintains wire compatibility.

Step 1: Audit Your Module Usage

# Check loaded modules on your current Redis instance
redis-cli MODULE LIST

# If this returns empty or only open-source modules, you're clear.
# If you see: search, ReJSON, timeseries, bf -- plan for alternatives.

Step 2: Update Client Configuration

// Node.js with ioredis -- change only the connection endpoint
import Redis from 'ioredis';

// Before (Redis)
const redis = new Redis({
  host: 'redis-primary.example.com',
  port: 6379,
  password: process.env.REDIS_PASSWORD,
});

// After (Valkey) -- only the host changes
const valkey = new Redis({
  host: 'valkey-primary.example.com',
  port: 6379,
  password: process.env.VALKEY_PASSWORD,
});

# Python with redis-py -- same client works
import redis

# Works with both Redis and Valkey
r = redis.Redis(
    host='valkey-primary.example.com',
    port=6379,
    password='your-password',
    decode_responses=True
)

Step 3: Data Migration

# Option A: RDB snapshot (simplest for standalone)
# On Redis source:
redis-cli BGSAVE
# Copy the dump.rdb to the Valkey data directory
cp /var/lib/redis/dump.rdb /var/lib/valkey/dump.rdb
# Start Valkey -- it loads the RDB file on startup

# Option B: Online replication (zero-downtime)
# Configure Valkey as a replica of the Redis primary:
valkey-cli REPLICAOF redis-primary.example.com 6379
# Wait for sync to complete:
valkey-cli INFO replication | grep master_sync_in_progress
# When sync is done, promote Valkey to primary:
valkey-cli REPLICAOF NO ONE
# Update application connection strings to point to Valkey

Step 4: Verify Configuration Compatibility

# Compare key configuration between Redis and Valkey
# Most redis.conf directives work in valkey.conf
# Key differences to check:

# Valkey 8.0 threading (not available in Redis 7.x default)
io-threads 4
io-threads-do-reads yes

# Persistence settings (identical syntax)
save 900 1
save 300 10
appendonly yes
appendfsync everysec

# Memory management (identical syntax)
maxmemory 4gb
maxmemory-policy allkeys-lru

Pro tip: If you run on AWS ElastiCache, the migration path is even simpler. Create a new ElastiCache cluster with the Valkey engine, enable Global Datastore or use the built-in migration tool to replicate data, then switch your application endpoints. AWS handles the replication and data transfer.

When to Stay on Redis

Despite Valkey's advantages, there are legitimate reasons to stay on Redis:

• You depend on RediSearch or RedisJSON -- no equivalent exists in the Valkey ecosystem today. Rearchitecting search or document storage is not trivial.
• You need Active-Active geo-replication -- Redis Enterprise offers conflict-free replicated data types (CRDTs) for multi-region active-active deployments. Valkey has no equivalent.
• You run on Azure -- Azure Cache for Redis is the only managed option. Running self-managed Valkey on Azure VMs negates the operational benefits of a managed service.
• Your legal team is fine with SSPL/RSALv2 -- if you self-host for internal use and do not offer Redis as a service, the license change has no practical impact on your deployment.
• You need Redis Insight or commercial support -- Redis Ltd. provides official tooling and enterprise support. The Valkey community is growing but does not yet offer comparable vendor-backed SLAs.

When to Switch to Valkey

• You use Redis as a cache, session store, or Streams-based message broker -- no module dependencies, API-compatible, and Valkey is faster.
• Your legal team flags SSPL -- BSD is universally accepted. SSPL is considered non-open-source by the OSI and rejected by most Linux distributions.
• You run on AWS -- ElastiCache defaults to Valkey. Swimming with the current is easier than against it.
• You want multi-threaded I/O -- Valkey 8.0's threading delivers 30%+ throughput gains on multi-core instances without application changes.
• You contribute to or depend on the open-source ecosystem -- Valkey's BSD license guarantees that your contributions and dependencies remain open.

Migration Failure Modes I've Watched Teams Hit

The Silent Module Dependency

You run MODULE LIST, it returns empty, you declare the migration safe, and two weeks later a Grafana dashboard breaks because it was pointing at a RedisTimeSeries database you forgot existed. Audit every application connection string, not just the main production cluster. Search your codebase for TS.CREATE, FT.CREATE, JSON.SET, and BF.ADD -- those commands will fail silently on Valkey (returning ERR unknown command) and clients that don't check return values won't notice until data goes missing.

The Persistence Config Mismatch

Redis defaults and Valkey defaults diverge slightly on persistence tuning. If you copy redis.conf into valkey.conf verbatim, AOF rewrite behaviour and appendfsync semantics are identical -- but io-threads is off by default in both. Teams enable threading on Valkey expecting automatic wins, forget to also set io-threads-do-reads yes, and see no performance improvement. The flag is required to benefit from threading on read-heavy workloads.

# Valkey threading config that actually helps
io-threads 4
io-threads-do-reads yes
# On an 8-vCPU instance, 4 I/O threads balances
# parallelism against contention overhead. Benchmark before tuning.

Client-Side RESP Version Drift

Some clients (older versions of ioredis, redis-py before 5.0) default to RESP2 while newer ones negotiate RESP3 by default. Valkey supports both. If your application relies on subtle differences in how maps vs. arrays are returned (hash commands like HGETALL return a flat array in RESP2, a map in RESP3), upgrading the client library during migration can surface bugs that had nothing to do with the server swap. Pin your RESP version with HELLO 2 on connection init until you're ready to change both.

Cluster Slot Migration Under Load

Valkey 8.0's async slot migration is faster than Redis 7.2's, but both can cause latency spikes during active resharding if your workload has hot keys. Plan migrations during low-traffic windows, monitor CLUSTER NODES output, and throttle with cluster-allow-reads-when-down no so stale reads don't leak during transfers.

Cost Comparison: Self-Hosted and Managed in 2026

Deployment	3-node cluster, 8 vCPU / 16 GB each	Monthly cost (us-east-1)
Self-hosted Valkey on EC2	c6i.2xlarge x 3 + storage	~$780
Self-hosted Redis OSS on EC2	c6i.2xlarge x 3 + storage	~$780
ElastiCache Valkey	cache.r7g.xlarge x 3	~$920
ElastiCache Redis OSS	cache.r7g.xlarge x 3	~$920
Redis Cloud (Redis Ltd.)	Flexible 10 GB x 3, multi-AZ	~$1,400
Redis Enterprise (self-managed)	3-node cluster license + EC2	$780 + license quote

On equivalent AWS infrastructure, Valkey and Redis OSS cost the same. The delta is commercial: Redis Cloud and Redis Enterprise include Active-Active replication, 24/7 support, and the proprietary modules. If your budget tolerates the premium and your workload uses those features, the price is defensible. If your workload is cache and sessions, you are paying for features you don't use. Most teams migrating to Valkey in 2024-2026 are doing so for licensing reasons first and the 30% throughput bump second.

Frequently Asked Questions

The Bottom Line

The Redis-to-Valkey fork is not a dramatic technical rupture -- it is a licensing and governance divergence that will widen over time. For the majority of Redis deployments that use standard data structures (caching, sessions, rate limiting, pub/sub, streams), Valkey is a faster, BSD-licensed drop-in replacement. For deployments that depend on Redis's proprietary module ecosystem (search, JSON documents, time series, probabilistic structures), Redis remains the integrated option.

Make your decision based on three factors: module dependencies, cloud provider alignment, and license requirements. Everything else -- performance, stability, community support -- favors Valkey for standard workloads and favors Redis for module-heavy workloads. Pick the one that matches your actual usage, not the one with more hype.