Redis 8 vs Valkey: The Fork That Split the Caching World

Redis Ltd. changed Redis to a dual license (RSALv2 + SSPLv1) that prevents cloud providers from offering managed Redis services. The Linux Foundation forked it as Valkey under a BSD license. Redis 8 vs Valkey — which should you choose? This guide cuts through the licensing drama to focus on what matters in production: technical differences, migration effort, operational behavior, and long-term risk.

What Actually Happened

In March 2024, Redis Ltd. (the company, formerly Redis Labs) changed Redis’s license from BSD to a dual RSALv2/SSPL license. This means cloud providers (AWS, GCP, Azure) can no longer offer managed Redis services using the Redis source code. Additionally, any company that embeds Redis into a product they sell as a service is affected.

In response, the Linux Foundation launched Valkey — a fork of Redis 7.2.4, the last BSD-licensed version — with backing from AWS, Google, Oracle, Ericsson, and Snap. Valkey is fully open-source under the BSD license and aims to be a drop-in replacement.

For you as a developer or operator, the impact depends on how you use Redis:

Self-hosted Redis for your own apps: The license change doesn’t affect you. You can use Redis 8 freely for your own applications.
Managed cache service (ElastiCache, Memorystore): AWS has already switched ElastiCache to Valkey. GCP Memorystore is transitioning. Your managed service may already be Valkey under the hood.
Embedding the engine in a product you sell: You need to evaluate the RSAL/SSPL restrictions. Valkey is the safe choice.

Technical Comparison: Redis 8 vs Valkey

Both projects started from the same codebase. Here’s where they’ve diverged as of early 2026:

COMPATIBILITY (as of March 2026):
  Protocol:           Both fully compatible (RESP2 + RESP3)
  Commands:           99.9% compatible (each side added a few)
  Stack modules:      Redis Stack modules are NOT available in Valkey
  Sentinel:           Both supported
  Cluster:            Both supported
  Client libraries:   All Redis clients work with Valkey (same protocol)

REDIS 8 EXCLUSIVE FEATURES:
  - Redis Search (full-text + vector search built-in)
  - Redis JSON (native JSON document type)
  - Redis Time Series
  - Redis Bloom (probabilistic data structures)
  These ship as "Redis Stack" — bundled in Redis 8 under the new license

VALKEY EXCLUSIVE FEATURES:
  - Multi-threaded command execution (faster at high connection counts)
  - Improved memory efficiency and per-key overhead reductions
  - RDMA transport support for cluster replication
  - Community-driven development with faster release cycles

PERFORMANCE:
  Single-thread operations: Identical (same core engine)
  Multi-connection throughput: Valkey wins with multi-threading
  Memory efficiency: Comparable (Valkey slightly better in cluster mode)
  Latency p99: Identical for standard operations

The single most consequential technical difference is threading. Classic Redis executes commands on one main thread; Valkey extends multi-threading from just I/O into command execution, so a box with many cores and many connections can push noticeably higher throughput. For a small cache fronting a web app, you will never notice this. For a multi-tenant cache saturating a 16-core node, however, it is the difference that can justify the migration on its own.

Configuration and Operational Differences

Day-to-day operation is nearly identical, which is the whole point of a drop-in fork. The configuration file format, the CLI (valkey-cli, which also accepts the redis-cli name), persistence with RDB and AOF, and the INFO output are all the same. Therefore most Ansible roles, Helm charts, and monitoring dashboards work after only changing the image name.

The seams to watch are the small ones. Valkey ships its binaries as valkey-server and valkey-cli with compatibility symlinks, so init scripts that hard-code /usr/bin/redis-server need a path tweak. Likewise, metrics exporters that scrape the redis_version field will report a Valkey version string, which can trip alerting rules that pin an expected version. A common pattern is to template the binary path and treat the version field as informational rather than a gate.

# docker-compose.yml — swapping the engine is a one-line image change
services:
  cache:
    # image: redis:8           # before
    image: valkey/valkey:8     # after — same port, same config, same data dir
    command: ["valkey-server", "/etc/valkey/valkey.conf"]
    ports:
      - "6379:6379"
    volumes:
      - ./valkey.conf:/etc/valkey/valkey.conf:ro
      - cache-data:/data
volumes:
  cache-data:

Redis vs Valkey performance comparison — Core performance is identical — differences emerge in modules and multi-threaded execution

Migration from Redis to Valkey

For standard usage — caching, sessions, pub/sub, sorted sets — migration is straightforward because Valkey is wire-compatible. Your existing client libraries (redis-py, ioredis, Jedis, go-redis) work without code changes. Just point them at the Valkey endpoint.

# Your existing Redis code works with Valkey unchanged
import redis

# Before: Redis
# client = redis.Redis(host='redis.internal', port=6379)

# After: Valkey — same client library, different host
client = redis.Redis(host='valkey.internal', port=6379)

# All operations work identically
client.set('user:1001:session', session_data, ex=3600)
client.hset('product:xyz', mapping={'name': 'Laptop', 'price': '999.99'})
client.zadd('leaderboard', {'player1': 100, 'player2': 95})
result = client.zrangebyscore('leaderboard', 90, 100)

For a live cutover, the safe pattern is replica promotion: stand up a Valkey instance as a replica of the running Redis primary using REPLICAOF, let it catch up, then promote it and repoint clients. Because the replication protocol is shared, this gives you a near-zero-downtime move with a built-in rollback — if anything looks wrong, you have not yet decommissioned the original primary.

# 1. Bring up Valkey and replicate from the existing Redis primary
valkey-cli -h valkey.internal REPLICAOF redis.internal 6379

# 2. Watch until the replica is in sync
valkey-cli -h valkey.internal INFO replication | grep master_link_status
# master_link_status:up   <- ready to promote

# 3. Detach and promote, then repoint application traffic
valkey-cli -h valkey.internal REPLICAOF NO ONE

If you use Redis Stack modules (Search, JSON, TimeSeries), migration is harder because Valkey doesn't include them. You will need to either keep Redis for those features, migrate to alternatives — Elasticsearch or a dedicated vector database for search, PostgreSQL JSONB for documents, TimescaleDB for time series — or wait for community module equivalents to mature. Treat any module dependency as the real decision point, not the license itself.

Which Should You Choose?

Choose Valkey when: you use a managed cloud service (it may already be Valkey), you want fully open-source with no license risk, you don't depend on Redis Stack modules, you run high-connection-count workloads that benefit from multi-threading, or you're starting a new project and want the safest long-term default.

Choose Redis 8 when: you need Redis Stack modules and don't want to operate separate tools for search, JSON, or time series, you're self-hosting for your own applications (the license doesn't restrict that), or you have Redis Enterprise support contracts and value vendor-backed support.

Caching architecture decision — For standard caching: Valkey. For Redis Search/JSON/TimeSeries: Redis 8. For new projects: Valkey.

The Long-Term Outlook and Trade-offs

Valkey has momentum: AWS, Google, and Oracle are backing it, major providers are migrating their managed offerings, and the contributor base is growing quickly. Redis has a strong product story with the integrated Stack but faces increasing isolation as the cloud ecosystem standardizes on the fork. The honest trade-off is governance versus features — Valkey gives you a vendor-neutral foundation, while Redis 8 gives you a richer batteries-included engine at the cost of license constraints.

One risk worth naming: forks can drift. Today the two are wire-compatible, but as Valkey adds threading internals and Redis adds Stack capabilities, command-level parity could erode over a few years. For most teams the practical advice is to use Valkey for new deployments, migrate existing Redis when convenient, and only stay on Redis if you have a hard dependency on Stack modules — while keeping your client code free of engine-specific commands so a future switch stays cheap.

Related Reading:

Resources:

In conclusion, Redis 8 vs Valkey is primarily a licensing and governance decision; technically the two are nearly identical for standard use cases. Choose Valkey for open-source safety, cloud compatibility, and multi-threaded throughput. Choose Redis 8 if you genuinely need the proprietary Stack modules. Either way, keep your client code engine-agnostic and your migration path — via replica promotion — stays simple and reversible.