The Day Our Redis Bill Became a Legal Question
March 2024. Our team was mid-way through a routine infrastructure review when the news dropped: Redis Ltd. had relicensed Redis from BSD to a dual license — RSALv2 and SSPL. For most small teams self-hosting Redis, this changed nothing. But we weren’t a small team. We were building a SaaS platform, and suddenly our legal team was asking uncomfortable questions about what SSPL meant for our product.
Six months later: three environments fully migrated — development, staging, and production. Here’s exactly what worked, what didn’t, and what we wish we’d known going in.
What Actually Happened with Redis Licensing
The short version: Redis Ltd. felt that major cloud providers (AWS, Azure, GCP) were profiting massively from Redis without contributing back to the project. Their solution was to switch to SSPL — the same license MongoDB used in 2018 — which essentially requires any company offering Redis as a service to open-source their entire stack.
SSPL is deliberately broad. If Redis is a component in your commercial product, your legal team will spend weeks deciding whether your specific usage triggers its terms. That ambiguity has a real cost: blocked engineering decisions, billed lawyer hours, and eventually a migration anyway. Redis 7.2.x was the last version under BSD. Everything after is under the new license.
Root Cause: Why the Old Options Don’t Work
Staying on Redis 7.2 forever sounds appealing until you think it through. Security patches, new data structure features, and client library compatibility all move forward. Freeze at 7.2 and you accumulate technical debt with every release cycle you skip — and those cycles don’t stop.
We also looked at what alternatives existed before Valkey appeared, and none of them fit cleanly:
- Memcached is genuinely BSD-licensed and fast, but it’s a pure key-value cache. We relied heavily on sorted sets for leaderboards, streams for event queues, and pub/sub for real-time notifications. Migrating to Memcached would mean rewriting significant application logic.
- KeyDB forked from Redis and added multi-threading. Snapchat acquired it, open-sourced it, and it’s been quiet ever since. Releases are infrequent, community activity is thin, and it wasn’t a bet we wanted to make on a critical dependency.
- Dragonfly takes a fundamentally different approach internally — redesigned data structure layer, claimed better memory efficiency. Promising on paper, but it was new enough to have Redis command compatibility gaps that would have required application changes on our end.
The licensing change, combined with the limitations of existing alternatives, is exactly why the Linux Foundation stepped in so quickly.
Valkey vs. the Alternatives: Why We Chose It
Valkey forked from Redis 7.2.4 — the last BSD-licensed release — immediately after the license change. The Linux Foundation now governs it, with AWS, Google, Oracle, and Ericsson as active contributors. That governance model matters: no single vendor controls the roadmap.
| Option | License | API Compatibility | Community |
|---|---|---|---|
| Redis 7.4+ | RSALv2/SSPL | Full | Large, vendor-led |
| Valkey 8.x | BSD 3-Clause | Full (7.2) | Growing, foundation-backed |
| KeyDB | BSD | Mostly full | Small |
| Dragonfly | BSL 1.1 | Partial | Small |
| Memcached | BSD | None | Stable, minimal |
Drop-in replacement, active development, BSD license, foundation-backed governance with no SSPL ambiguity. That combination closed the discussion for us pretty quickly.
Installing Valkey
Ubuntu/Debian via APT
curl -fsSL https://packages.valkey.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/valkey-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/valkey-archive-keyring.gpg] https://packages.valkey.io/apt $(lsb_release -cs) main" \
| sudo tee /etc/apt/sources.list.d/valkey.list
sudo apt update && sudo apt install valkey -y
sudo systemctl enable valkey --now
# Verify
valkey-cli PING # should return PONGDocker Compose (What We Actually Use)
services:
valkey:
image: valkey/valkey:8
restart: unless-stopped
ports:
- "6379:6379"
volumes:
- valkey_data:/data
- ./valkey.conf:/usr/local/etc/valkey/valkey.conf
command: valkey-server /usr/local/etc/valkey/valkey.conf
volumes:
valkey_data:Configuration
Valkey reads the same configuration format as Redis. Got an existing redis.conf? Rename it to valkey.conf, point Valkey at it, and it works without a single edit. Our production config looks like this:
# Memory
maxmemory 2gb
maxmemory-policy allkeys-lru
# Persistence — RDB + AOF
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
# Security
requirepass your_strong_password_here
bind 127.0.0.1
# Performance
tcp-backlog 511
hz 10
lazyfree-lazy-eviction yesMigrating from Redis: Three Approaches
Method 1: RDB Dump (Best for Scheduled Maintenance Windows)
Redis and Valkey share the same RDB format for 7.x. This is what we used for non-production environments:
# On your Redis server — trigger a background save
redis-cli BGSAVE
# Check when it finished
redis-cli LASTSAVE
# Copy the dump to the new Valkey server
scp /var/lib/redis/dump.rdb user@new-server:/data/valkey/dump.rdb
# Start Valkey — it loads the dump automatically
sudo systemctl start valkey
# Verify key count matches
valkey-cli DBSIZEMethod 2: Replication-Based (Zero Downtime)
When your uptime SLA doesn’t allow a maintenance window, run Valkey as a replica of your Redis primary first. This is what we used for the production cutover:
# On the Valkey server — join as replica of existing Redis
valkey-cli REPLICAOF redis-primary-ip 6379
# Monitor replication until caught up
valkey-cli INFO replication
# Look for: master_sync_in_progress:0 and master_link_status:up
# Update application connection strings to point at Valkey
# Then promote Valkey to primary
valkey-cli REPLICAOF NO ONE
# Shut down old Redis
sudo systemctl stop redisMethod 3: Selective Key Migration (Useful for Cleanup)
Migration is also a good time to prune stale keys rather than carry them forward:
#!/bin/bash
# Migrate specific key patterns from Redis to Valkey
# Note: replace KEYS with SCAN on large datasets to avoid blocking
REDIS_HOST="old-redis-host"
VALKEY_HOST="new-valkey-host"
for key in $(redis-cli -h $REDIS_HOST KEYS "session:*"); do
ttl=$(redis-cli -h $REDIS_HOST TTL "$key")
dump=$(redis-cli -h $REDIS_HOST DUMP "$key")
if [ "$ttl" -gt 0 ]; then
valkey-cli -h $VALKEY_HOST RESTORE "$key" $((ttl * 1000)) "$dump"
else
valkey-cli -h $VALKEY_HOST RESTORE "$key" 0 "$dump"
fi
doneApplication Changes Required
Using redis-py in Python? One change: the host. That’s it:
# Before
import redis
client = redis.Redis(host='old-redis-host', port=6379, password='secret')
# After — just the host changes
import redis
client = redis.Redis(host='valkey-host', port=6379, password='secret')
# Or install the valkey package for an explicit dependency
# pip install valkey
import valkey
client = valkey.Valkey(host='valkey-host', port=6379, password='secret')The valkey Python package is a maintained fork of redis-py with an identical API. Node.js users on ioredis or node-redis: same story — update the connection string and you’re done.
One thing that will catch you: monitoring scripts and health checks calling redis-cli PING need to switch to valkey-cli PING. Binary names changed. Commands didn’t.
Six Months In: What We’ve Actually Seen
Memory usage runs about 5–8% lower than equivalent Redis 7.2 under our workload. Valkey 8.0’s I/O threading improvements made a measurable difference for our pub/sub-heavy services — better throughput on multi-core servers, no configuration changes required on our end.
Command compatibility has been solid across everything we use: strings, hashes, sorted sets, streams, pub/sub, Lua scripting, and transactions. Zero incompatibilities across six months of production traffic.
During the migration, we needed to convert some CSV configuration exports to JSON to update our deployment scripts. We used toolcraft.app/en/tools/data/csv-to-json for that — it runs entirely in the browser, so no config data leaves your machine. Useful for infrastructure work where pasting sensitive values into an unknown web service isn’t an option.
Total time across three environments: roughly two days. Most of that went to testing and updating monitoring dashboards, not actual data movement. Each environment’s data migration took under an hour. The replication-based production cutover had zero downtime.
Is Valkey Right for Your Setup?
Self-hosting Redis 7.2 or earlier with something commercial built on top? Get ahead of the SSPL question before your lawyer brings it up at the wrong moment. Valkey gives you a clear path: same API, active maintenance, BSD license, and governance that no single vendor controls.
Already on Redis Enterprise or a managed service like ElastiCache with licensing handled? The migration cost probably isn’t justified — stay put. But for self-hosted open-source Redis in a commercial product, Valkey is the most direct exit available. We expected a week of integration work. In practice, it landed closer to an afternoon per environment.
