Redis and Valkey: Version Compatibility, Licensing and Migration Planning

Redis and Valkey are options for in-memory data structures and caching. Choosing between them requires checking the exact versions, licenses, application behavior and operational requirements; neither belongs in every docker-compose.yml by default.

The licensing timeline matters: Redis 7.2 and earlier remain BSD-3-Clause; Redis 7.4 uses RSALv2 or SSPLv1. Redis 8 added AGPLv3 as a third option, announced on May 1, 2025. Valkey follows a separate BSD-licensed development line. This is a version summary, not advice that a particular deployment meets license obligations.

We will examine documented differences, a disposable local example and migration planning. No installation or migration was performed, and this article does not promise production compatibility, zero downtime or lower cost.

What is Valkey and Why Does It Matter?

The Linux Foundation announced the Valkey community on March 28, 2024. Its announcement named AWS, Google Cloud, Oracle, Ericsson and Snap among supporters; this is historical project support, not certification of any deployment.

Valkey originated from Redis OSS 7.2.4 and uses BSD-3-Clause licensing. Its later releases include documented engineering changes, but corporate backing alone is not evidence of better performance than another product.

For developers, Valkey offers:

Licensing: BSD-3-Clause provides permissions with conditions, including notice requirements. It does not eliminate compliance work, service charges or uncertainty about future releases. Review the exact distribution and dependencies.
Protocol compatibility: Valkey supports RESP2 and RESP3, and many Redis clients can connect. Still test your exact ioredis, redis-py or go-redis version, commands, reply shapes, scripts, modules and topology. Protocol compatibility is not universal application equivalence.
Versioned improvements: Valkey 8.0 and 8.1 document I/O and memory-layout changes. Their benefit depends on workload and configuration; they are not features to infer from the source’s 7.2 image tag.

Under the Hood: Where Valkey and Redis Diverge

Compatibility has a version boundary. The migration guide covers Redis OSS through 7.2; it explicitly excludes direct use of data files from Redis CE 7.4 and later. New commands and modules require separate validation, so “100% API compatibility” is not an appropriate blanket claim.

Threaded Architecture and I/O

For the documented Valkey 8.0/8.1 design, I/O threads handle work such as network reads, parsing and responses while command execution remains on the main thread. This is not general parallel execution of all commands.

I/O offloading can free main-thread capacity for suitable workloads. Published project results have specific hardware and test conditions; they do not establish better throughput per dollar for every Graviton, Tau or other cloud instance. This article provides no benchmark.

Memory Efficiency

Valkey 8.0 documents per-slot dictionaries and key embedding; 8.1 documents a new hash-table implementation. These are concrete changes, not a guarantee of flat p99 latency or lower memory use for every dataset. Compare memory, latency distributions and persistence settings using representative workloads.

Spinning Up Valkey Locally: A Developer's Quickstart

The following unexecuted Compose fragments describe separate disposable labs, not a data migration. Supply reviewed image digests for the stated release families; they intentionally have no production volume and disable persistence. Use synthetic data only.

Compare these docker-compose.yml fragments. Host ports are explicitly loopback-bound and distinct. This is not authentication or a complete isolation boundary; inspect Docker routing/firewall configuration. Docker documents a localhost-publishing caveat for releases before 28.0.0.

Separate Redis 7.2 lab specification

services:
  cache:
    image: "${REDIS_LAB_IMAGE:?Set a reviewed Redis 7.2 image digest}"
    command: ["redis-server", "--save", "", "--appendonly", "no"]
    ports:
      - "127.0.0.1:6380:6379"
    tmpfs:
      - /data

Separate Valkey 8.1 lab specification

services:
  cache:
    image: "${VALKEY_LAB_IMAGE:?Set a reviewed Valkey 8.1 image digest}"
    command: ["valkey-server", "--save", "", "--appendonly", "no"]
    ports:
      - "127.0.0.1:6381:6379"
    tmpfs:
      - /data

Both fragments use container port 6379, but the host ports differ. Creating a volume with a new name does not copy an old volume’s data. Matching a port and several commands is not enough to establish application compatibility.

A limited Node.js compatibility illustration

This CommonJS illustration targets the inspected ioredis 5.8.2 option API. It defines a function but does not call it. Only after independently preparing an authorized disposable Valkey lab would calling it connect to 127.0.0.1:6381 and write two synthetic keys. Review the dependency version before any use.

const Redis = require('ioredis');
const { randomUUID } = require('node:crypto');

async function runSyntheticDemo() {
  const client = new Redis({
    host: '127.0.0.1', port: 6381,
    lazyConnect: true,
    connectTimeout: 2000,
    commandTimeout: 2000,
    maxRetriesPerRequest: 0,
    retryStrategy: () => null,
    enableOfflineQueue: false,
  });
  client.on('error', () => {});
  const prefix = `sysseder:synthetic:${randomUUID()}`;
  const valueKey = `${prefix}:value`;
  const hashKey = `${prefix}:hash`;
  try {
    await client.connect();
    const value = JSON.stringify({ example: 'synthetic', count: 1 });
    if (await client.set(valueKey, value, 'EX', 60) !== 'OK') {
      throw new Error('Unexpected SET reply');
    }
    if (await client.get(valueKey) !== value) {
      throw new Error('GET mismatch');
    }
    await client.hset(hashKey, 'example', 'synthetic', 'count', '1');
    if (await client.expire(hashKey, 60) !== 1) {
      throw new Error('EXPIRE failed');
    }
    const fields = await client.hgetall(hashKey);
    if (fields.example !== 'synthetic' || fields.count !== '1') {
      throw new Error('HGETALL mismatch');
    }
    return 'Selected synthetic round-trip checks completed';
  } finally {
    client.disconnect();
  }
}

module.exports = { runSyntheticDemo };

If later tested, SET, GET, HSET and HGETALL cover only these simple cases. There is no captured successful run. The hash write and expiration are separate operations: interruption between them can leave a key without a TTL, so the example requires a disposable database. A timeout does not prove that the server did not apply a write.

Production migration planning, not an operational runbook

Plan compatibility tests, validated recovery material, write coordination and rollback before a production migration. Replication is asynchronous; neither this outline nor a promotion command guarantees zero downtime or zero data loss. Cluster/Sentinel topologies need their own reviewed plan.

Option 1: evaluate a version-compatible replication cutover

Valkey’s guide describes replication-based migration from compatible Redis OSS versions through 7.2. Do not assume that a newer Redis primary, modules or a managed-service endpoint can use the same procedure. Verify the exact source/target pair and access controls in staging first.

Prepare an isolated staging target and a documented rollback plan; do not attach this example to production.
Review version compatibility, replication credentials, transport protection and allowed network paths before designing a replica relationship. No live REPLICAOF command is supplied here.
Use replication status and offsets to assess synchronization and lag during a separately authorized test. A successful initial sync does not mean all later writes are durable on the replica.
Run representative read/write compatibility and latency tests in staging with approved synthetic data, rather than diverting live user traffic for an unvalidated experiment.
Before any authorized promotion, coordinate a write freeze or another validated write-routing protocol, verify final synchronization, and prevent two writable primaries. The source’s standalone promotion command is not a complete cutover procedure.
Plan client reconnection, endpoint changes, validation and rollback together. Once the new primary accepts writes, simply pointing back to the old one can lose or diverge data; reconcile state under the reviewed migration plan.

Option 2: Snapshot Restore

Snapshot migration requires compatible dump.rdb data and a maintenance window measured for the actual dataset. Restore time is not universally a few minutes. Account for writes after the snapshot and for AOF/module configuration.

Choose and validate an appropriate snapshot procedure. SAVE is synchronous and blocks other clients; do not casually issue it on a live service. Background saving also has resource and consistency considerations.
Verify that the expected snapshot completed and can be restored in staging; protect its contents and retain the original recovery material under the organization’s retention policy.
Coordinate the final write boundary and maintenance window before stopping any authorized source service. Do not treat a stop command as the whole consistency plan.
Check the target’s configured data directory, ownership, persistence mode and format compatibility before arranging a restore. Never overwrite the only recoverable dataset.
A correctly configured compatible target may load an RDB at startup; if AOF is enabled, its startup precedence also matters. Validate load errors, key values, TTLs and application behavior before opening traffic. No restore was performed here.

Is Valkey Ready for Enterprise Production?

Readiness depends on your requirements. Evaluate supported versions, operations expertise, recovery objectives, security controls and the required command/module set. Project adoption is not a substitute for that assessment.

For a managed service, compare the provider’s currently offered engine versions, features, regions, support terms and total workload cost. This article makes no current vendor availability or price comparison and does not infer an industry baseline from sponsorship.

A migration has engineering and operational costs as well as licensing considerations. Decide from validated requirements, not an assumed saving or a promised future direction.

Wrapping Up

Governance and licensing affect how a project evolves, but neither guarantees secure software. Valkey’s community model and Redis’s license options should be evaluated alongside maintenance, security updates and deployment controls.

For a new project, compare Redis and Valkey against the same functional, licensing and operational requirements. A representative test and recovery rehearsal are more useful than a universal claim that either engine is faster, cheaper or the only open choice.

Over to you: Have you made the switch to Valkey yet, or are you planning a migration in your organization? Let me know your thoughts, worries, or success stories in the comments below!