Valkey vs Redis: What the Fork Means for Your Stack

The Fork That Reshaped the In-Memory Database Market

In March 2024, Redis Ltd. changed the license for Redis from the permissive BSD 3-Clause to a dual license combining the Server Side Public License (SSPL) and Redis Source Available License v2 (RSALv2). The move effectively barred cloud providers from offering Redis as a managed service without a commercial agreement. Within weeks, the Linux Foundation announced Valkey -- a community-driven fork of Redis 7.2.4 under the BSD 3-Clause license.

Eighteen months later, both projects have shipped major releases. Valkey 8.0 introduced multi-threaded I/O and significant memory optimizations. Redis 8.0 doubled down on integrated vector search and JSON support. If you are running Redis in production today, you face a real decision: stay with Redis under the new license terms, migrate to Valkey, or run both. This article breaks down the technical differences, benchmarks, migration path, and ecosystem gaps so you can make that call with confidence.

What Is Valkey?

Definition: Valkey is an open-source, BSD-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, including native multi-threaded I/O and memory-efficient data encoding. 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" -- straightforward and intentional. Valkey is not a clean-room reimplementation. It shares the Redis codebase at the point of the fork and maintains wire-protocol compatibility with RESP2 and RESP3. Existing Redis clients (Jedis, ioredis, redis-py, Lettuce) connect to Valkey without code changes.

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.

Frequently Asked Questions

Is Valkey fully compatible with Redis?

Valkey 8.0 is wire-compatible with Redis via RESP2 and RESP3 protocols. All standard Redis commands (strings, hashes, lists, sets, sorted sets, streams, pub/sub, Lua scripting, ACLs) work identically. Existing Redis clients connect to Valkey without code changes. The incompatibility is limited to proprietary Redis modules (RediSearch, RedisJSON, RedisTimeSeries, RedisBloom) which are not available on Valkey due to licensing.

Will Valkey and Redis diverge further over time?

Yes, and they already have. Valkey is investing in core engine optimizations (multi-threaded I/O, memory efficiency, cluster improvements) while Redis is integrating proprietary modules into the core binary and adding features like vector search. The APIs for standard data structures will likely remain compatible for years, but new features will be project-specific. Plan for eventual divergence if you adopt either one heavily.

Can I use RediSearch with Valkey?

No. RediSearch is licensed under Redis Source Available License, which is incompatible with Valkey's BSD license. If you need full-text search or vector similarity search alongside your key-value store, consider running a dedicated search engine (OpenSearch, Meilisearch, Typesense) or using PostgreSQL with pgvector for vector workloads. The Valkey community has discussed building open-source alternatives, but nothing production-ready exists yet.

How does the Valkey multi-threaded I/O work?

Valkey's I/O threading offloads network read/write operations to a pool of worker threads while keeping command execution single-threaded. This means the data model remains thread-safe (no locking, no race conditions on data) while the network layer scales across CPU cores. Configure it with io-threads 4 and io-threads-do-reads yes in valkey.conf. On an 8-core instance, 4 I/O threads is a good starting point. The benefit is most visible under high connection counts and large payload sizes.

What happens to my ElastiCache Redis clusters on AWS?

Existing ElastiCache Redis clusters continue to run. AWS has not announced forced migration. New clusters default to the Valkey engine, but you can still select Redis. AWS recommends Valkey for new deployments. If you need to migrate, ElastiCache provides a built-in engine migration path that handles data replication with minimal downtime. Check the AWS documentation for your region's availability.

Is Valkey production-ready?

Yes. Valkey 8.0 is running in production at AWS (powering ElastiCache and MemoryDB), Oracle Cloud, and numerous companies that contributed to the fork. The Linux Foundation governance model, combined with contributors from AWS, Google, Oracle, Ericsson, and Snap, provides a level of organizational backing that exceeds most open-source projects. The project maintains a rigorous release and testing process inherited from the Redis codebase.

Should I wait before migrating?

If you have no module dependencies and no licensing concerns, there is no technical reason to wait -- Valkey 8.0 is stable and offers better performance for standard workloads. If you depend on RediSearch or RedisJSON, wait until community alternatives mature or plan to offload those workloads to dedicated services. For teams on Azure with managed Redis, waiting makes sense because no managed Valkey option exists there yet.

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.