Redis vs Valkey After the License Drama

License Drama: What Actually Happened

Look. Redis went from BSD to a source-available dual license (RSALv2 + SSPL) in March 2024, and if you were in a corporate setting, someone lost sleep over that. For self-hosters, it was more of a “oh, cool, now I have actual alternatives” moment.

Here’s the short version: Redis Labs realized they were getting crushed by cloud vendors running their code without giving back. They went source-available (SSPL is the same license MongoDB uses) instead of just forking off a new company name. Except—plot twist—the open-source community went full fork mode. Then, in May 2025, Redis backpedaled: Redis 8 added the AGPLv3 option, an OSI-approved open-source license, alongside the source-available tiers. Too late to undo the fork, though. Now you’ve got Valkey (Linux Foundation’s Redis fork, BSD 3-Clause), KeyDB (Snap’s fork, also BSD), and Redis itself (AGPLv3 or source-available, your pick). Everyone selling Redis-as-a-service got a scare. Self-hosters? You just got options.

That’s actually good news. Let’s talk about what that means for your next deploy.

The License Breakdown: What Matters to You

Redis (AGPLv3 or source-available) — Since Redis 8, you can run it under AGPLv3, an actual OSI-approved open-source license. For your own infrastructure that’s totally fine. The AGPL catch only bites if you offer Redis itself as a network service to others—then you’d have to share your modifications. Don’t want AGPL? The source-available tiers (RSALv2/SSPL) are still there.

Valkey (BSD 3-Clause) — Forked straight from Redis 7.2.4, maintained by the Linux Foundation. Zero licensing drama. You run it, you modify it, you ship it in your product. No lawyers needed. This is the “pick this if you want to stop worrying” option—and it’s now the default Redis-compatible cache shipped by Debian, Ubuntu, Fedora, and Arch.

KeyDB (BSD 3-Clause) — Another fork (now under Snap), permissively licensed, that adds some nice clustering tricks out of the box. If you want better cluster support without Sentinel complexity, this one’s worth a look.

tl;dr: Self-hosting only? Any of them are fine. Building a product and want zero AGPL questions? Valkey or KeyDB. Want clustering without the Redis Cluster learning curve? KeyDB. Need to be absolutely sure your legal team sleeps? Valkey.

Migration Path: From Redis to Valkey

Here’s the thing: Valkey is a drop-in replacement for 99% of Redis use cases. Same commands, same data format, same Lua scripting. Switching is boring, which is exactly what you want.

Step 1: Back Up Your Data

redis-cli --rdb /tmp/dump.rdb

That’s it. Your Redis dump is portable across all three (Valkey, KeyDB, Redis). BGSAVE in production is your friend—it won’t lock your database.

Step 2: Spin Up Valkey

Docker Compose replacement for Redis → Valkey:

version: '3.9'
services:
  valkey:
    image: valkey/valkey:8.0
    container_name: valkey
    ports:
      - "6379:6379"
    volumes:
      - valkey_data:/data
    command: |
      valkey-server
      --appendonly yes
      --appendfilename "appendonly.aof"
      --dir /data
    restart: unless-stopped

volumes:
  valkey_data:

Compare to old Redis Compose:

version: '3.9'
services:
  redis:
    image: redis:7.4-alpine
    container_name: redis
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes --dir /data
    restart: unless-stopped

volumes:
  redis_data:

See the diff? Image name, and Valkey uses valkey-server instead of redis-server. Everything else is identical.

Step 3: Load Your Backup

valkey-cli -p 6379 < /tmp/dump.rdb

Wait, that’s not quite right. If you backed up with RDB, load it while Valkey is stopped, then restart:

docker cp /tmp/dump.rdb valkey:/data/dump.rdb
docker restart valkey

Valkey loads the RDB on startup automatically. Done.

Step 4: Verify

valkey-cli ping
# PONG
valkey-cli keys "*"
# Your keys here

No downtime. No data loss. Your app keeps talking to :6379 and never notices.

Persistence: RDB vs AOF (and When to Care)

Both Redis and Valkey give you two persistence modes. Pick the wrong one and you’ll regret it at 2 AM when the power flicks.

RDB (Snapshot)

• Happens every N seconds (default: save 3600 1 = once an hour if 1+ key changed)
• Ultra fast on recovery (single binary snapshot)
• Risk: if your server dies, you lose up to N seconds of writes
• File: dump.rdb, usually 100 MB–1 GB depending on dataset size

AOF (Append-Only File)

• Every write gets journaled to disk (or every second, configurable)
• Recovery is slower (replaying every command)
• Risk: almost zero data loss (you lose maybe the last 1 second)
• File: appendonly.aof, grows unbounded until rewritten (usually weekly)

The verdict: For self-hosted stuff, use AOF + RDB combo (both enabled):

command: |
  valkey-server
  --appendonly yes
  --appendfilename "appendonly.aof"
  --appendfsync everysec
  --save 3600 1
  --dir /data

This way: you get AOF’s safety + RDB’s speed on recovery. Valkey/Redis rewrites the AOF weekly automatically, so disk bloat isn’t a nightmare.

Clustering: Do You Actually Need It?

This is where Redis and Valkey start to show different teeth.

Redis Cluster — 6+ nodes minimum, requires Sentinel for failover, feels like operating a power grid instead of a cache. Useful if your dataset is 100 GB+ or you need sub-second failover.

Valkey Cluster — Same as Redis Cluster (it’s the same code), but slightly less drama on recent versions.

KeyDB — Ships with “Active-Active Replication” out of the box. Deploy two KeyDB nodes, both accept writes, conflicts merge with last-write-wins. Easier than Cluster, less powerful than Cluster. Goldilocks zone for most home labs.

Redis Sentinel — Not clustering, just failover. One primary, N replicas, Sentinel watches and promotes a replica if primary dies. This is what 99% of self-hosters actually need.

Sentinel: The Boring Choice That Works

version: '3.9'
services:
  valkey:
    image: valkey/valkey:8.0
    container_name: valkey-primary
    ports:
      - "6379:6379"
    volumes:
      - valkey_data:/data
    command: valkey-server --appendonly yes --dir /data
    restart: unless-stopped

  valkey-replica:
    image: valkey/valkey:8.0
    container_name: valkey-replica
    ports:
      - "6380:6379"
    volumes:
      - valkey_replica:/data
    command: valkey-server --appendonly yes --dir /data --replicaof valkey 6379
    depends_on:
      - valkey
    restart: unless-stopped

  sentinel:
    image: valkey/valkey:8.0
    container_name: valkey-sentinel
    ports:
      - "26379:26379"
    volumes:
      - sentinel_data:/data
    command: |
      valkey-sentinel /etc/valkey/sentinel.conf
      --port 26379
      --dir /data
      --sentinel monitor mymaster valkey 6379 1
      --sentinel down-after-milliseconds mymaster 5000
      --sentinel failover-timeout mymaster 10000
    depends_on:
      - valkey
    restart: unless-stopped

volumes:
  valkey_data:
  valkey_replica:
  sentinel_data:

Connect your app to Sentinel (port 26379), not to Valkey directly. Sentinel routes you to the primary, and if the primary dies, Sentinel promotes the replica. Your app reconnects automatically. Restart time: ~10 seconds. Data loss: zero.

Performance: Are They Actually Different?

Valkey forked from Redis 7.2.4, but it didn’t freeze there—it has its own roadmap now, and so does Redis (Redis 8 landed in 2025 with big throughput gains). Both have moved well past the fork point. Does the difference matter to you?

Both Redis 8 and recent Valkey ship things like:

• ACL v2 (slightly better permissions model)
• Sharded pub/sub (for cluster scenarios)
• A steady stream of command optimizations

In practice: For cache/session storage, the difference is noise. Your network latency kills any CPU advantage. Pick Valkey and sleep at night about licensing.

KeyDB added some multi-threading stuff, which on paper is faster. In practice: Redis/Valkey single-threaded gets you 50k–100k ops/sec easily, which is overkill for home lab. Your NAS is bottlenecked on disk I/O, not Redis throughput.

When to Migrate: Decision Tree

Stick with Redis (AGPLv3) if:

• You’re self-hosting only (not offering Redis itself as a service)
• You love Redis and don’t care about the fork drama
• Your legal team is fine with AGPL (or you grab the source-available tier)

Switch to Valkey if:

• You’re paranoid about licensing (reasonable)
• You run a product that uses Redis (essential)
• You want Apache 2.0 and sleep soundly (deserved)

Try KeyDB if:

• You want active-active replication without Cluster complexity
• You need slightly simpler failover than Sentinel

The Migration Checklist

1. Backup your Redis dump (redis-cli --rdb /tmp/dump.rdb)
2. Spin up Valkey in a new container (don’t delete Redis yet)
3. Load the dump into Valkey
4. Run your app against Valkey (update your Compose file)
5. Monitor for 24 hours — watch for errors, no command incompatibilities should hit
6. Delete the Redis container when confident
7. Delete the Redis images to reclaim disk space

Total downtime: zero. Total drama: zero. Total sanity gained: immense.

Bottom Line

Redis going SSPL was a wake-up call that open-source infrastructure matters. Valkey proved the community can fork and maintain something properly. For 2026, you’ve got real choices instead of being locked to one vendor’s whims.

If you’re self-hosting and paranoid about licensing—which is reasonable—Valkey is the move, and it’s what your distro probably ships by default now anyway. If you’re fine with AGPL and don’t want to retrain your muscle memory, Redis 8 still works great. Either way, you’re not trapped. That’s the actual win here.

Pick one, deploy it via Compose, add Sentinel if you want failover, and go back to worrying about actual problems.

Related Reading

• Dragonfly vs Redis: Single-Binary Performance
• KeyDB: A Redis Fork With Multi-Threading
• DBeaver vs pgAdmin vs DataGrip
• MariaDB vs MySQL in 2026
• MongoDB Self-Hosted in 2026: SSPL and Alternatives