Valkey isn’t just Redis with a new name; it’s a fork that aims to be a community-driven, open-source alternative, actively addressing the licensing changes that made Redis less accessible for many.

Let’s see Valkey in action. Imagine you have a simple Redis setup storing user session data.

import redis

# Connect to your Redis instance
r = redis.Redis(host='localhost', port=6379, db=0)

# Set a session value
r.set('user:123:session', '{"token": "abc123xyz", "last_access": 1678886400}')

# Get the session value
session_data = r.get('user:123:session')
print(session_data.decode('utf-8'))

# Set an expiration for the session
r.expire('user:123:session', 3600) # Expires in 1 hour

Now, if you were to switch your client to connect to a Valkey instance running on the same host and port, the code would likely work without modification.

import redis # Note: The 'redis' client library often works with Valkey too!

# Connect to your Valkey instance
# If Valkey is on a different port or host, update these values
rv = redis.Redis(host='localhost', port=6379, db=0) # Assuming same port for demo

# Set a session value (same command)
rv.set('user:123:session', '{"token": "abc123xyz", "last_access": 1678886400}')

# Get the session value (same command)
session_data = rv.get('user:123:session')
print(session_data.decode('utf-8'))

# Set an expiration for the session (same command)
rv.expire('user:123:session', 3600)

The core problem Valkey solves is the shift in Redis’s licensing. Redis Labs (now Redis Inc.) changed the license of Redis from BSD to RSALv2/SSPLv1, which are considered non-open-source by many in the community. This meant that companies relying on Redis for their core infrastructure, especially those offering Redis-as-a-service, faced potential licensing conflicts or increased costs. Valkey emerged as a fork to ensure a truly open-source, community-governed path forward for the technology.

Internally, Valkey aims to maintain compatibility with the vast majority of Redis commands and data structures. The project is managed by the Linux Foundation, with a governance model designed to be more inclusive and transparent than what some perceived with Redis Inc.'s direction. This means contributions, feature development, and bug fixes are intended to be driven by a broader community.

When you migrate, the primary goal is to ensure your existing Redis workload can run on Valkey with minimal disruption. This involves:

  1. Installation: Setting up Valkey on your servers. This is typically done via package managers (if available) or by compiling from source.
  2. Configuration: Migrating your redis.conf (or equivalent) to Valkey’s configuration file. Most directives are identical, but there might be subtle differences or new options.
  3. Client Libraries: Ensuring your application’s Redis client library can connect to Valkey. Most popular libraries (like redis-py, node-redis, etc.) are designed to be protocol-compatible and will often work out-of-the-box with Valkey.
  4. Data Migration: This is the crucial part. For a live migration, you’ll want to set up replication.

The most common and robust way to migrate is using Valkey’s built-in replication capabilities, mirroring your Redis instance to a new Valkey instance.

Step-by-Step Migration Strategy (Live/Minimal Downtime):

  1. Set up a new Valkey instance: Install Valkey and configure it. Let’s say your current Redis is on redis.example.com:6379 and you’re setting up Valkey on valkey.example.com:6379.

  2. Configure Valkey for replication: On your Valkey instance, edit its configuration file (valkey.conf):

    replicaof redis.example.com 6379
    # Optional: If your Redis requires a password
    # masterauth <your_redis_password>
    

    Then restart Valkey.

  3. Monitor Replication: On the Valkey instance, run redis-cli -h valkey.example.com -p 6379 info replication. You should see master_sync_in_progress:1 and eventually master_sync_in_progress:0 with master_host and master_port pointing to your Redis.

  4. Switch Application Traffic: Once replication is caught up (check master_repl_offset on Redis and master_link_offset on Valkey are close or identical), you can update your application’s connection strings to point to valkey.example.com:6379.

  5. Promote Valkey: After traffic is successfully directed to Valkey, you can stop replication on the Valkey instance by running redis-cli -h valkey.example.com -p 6379 REPLICAOF NO ONE. This makes Valkey a standalone master.

  6. Stop Redis: Finally, shut down your old Redis instance.

The critical element that many overlook during this process is the replicaof command. When you configure Valkey with replicaof <masterip> <masterport>, Valkey initiates a full synchronization (a RDB dump and transfer) and then starts streaming the write commands from the Redis master. This ensures that Valkey stays up-to-date with all changes happening on your live Redis system before you switch your application over. It’s not just about copying data once; it’s about maintaining a live, synchronized copy.

After a successful migration to Valkey, your applications will likely encounter a new error if you attempt to use a Redis-specific module that hasn’t been ported or is incompatible with Valkey’s development path.

Want structured learning?

Take the full Redis course →