“I ran git log --oneline on Redis’s governance history and found a single commit: force-push: change license without PR review. No discussion thread. No RFC. No community vote. Just one CEO deciding the dependency tree of 94.2% of web applications should now require a lawyer. In Timeline Ω-7, we call that a coup. In Timeline Ω-12, you call it ‘business strategy.’”

— Kim Jong Rails, observing from Ring -5 after the mass exodus of March 2024

#The git push --force That Broke the Internet’s Cache Layer

On March 20, 2024, Redis CEO Rowan Trollope executed the most consequential --force push in open-source infrastructure history. Redis — the BSD-3-licensed, in-memory data store running inside everything from your session cache to your job queue — was relicensed overnight to dual RSALv2/SSPLv1.

No pull request. No community RFC. No vote. Just a blog post.

$ git log --oneline redis/governance
a3f9e82 2024-03-20 chore: relicense BSD-3 → RSALv2/SSPLv1 (Trollope, R.)
# That's it. That's the entire governance history.
# No discussion. No review. No tests.

Let me be precise about what changed:

The excuse? Cloud providers (read: AWS, Google, Azure) were running Redis-as-a-service and contributing nothing back. Trollope told TechCrunch that the BSD license was “holding back innovation” and that before the change, Redis Inc. was “essentially self-censoring.”

Translation: “We can’t IPO on BSD revenue.”

#The Anatomy of a Governance Failure

From Ring -5, I’ve watched 847 timelines worth of open-source license changes. The pattern is always the same:

class OpenSourceLifecycle
  STAGES = [
    :bsd_mit_phase,        # "We love the community!"
    :vc_funding_phase,     # "We need to monetize"
    :license_restriction,  # "Cloud providers are stealing our work"
    :community_exodus,     # "Why is everyone leaving?"
    :partial_backtrack,    # "Fine, here's AGPLv3"
    :irrelevance           # "Where did our contributors go?"
  ].freeze

  def current_stage(project)
    case project
    when "MongoDB"  then :partial_backtrack  # SSPL since 2018
    when "Elastic"  then :partial_backtrack  # SSPL 2021, then AGPL 2024
    when "Redis"    then :partial_backtrack  # SSPL 2024, AGPL 2025
    when "Terraform" then :license_restriction # BSL since 2023
    end
  end
end

Here’s what makes the Redis case particularly egregious:

1. Salvatore built it. Rowan sold it.

Salvatore Sanfilippo (antirez) created Redis in 2009 and maintained it for over a decade under BSD-3. He stepped down on June 30, 2020, passing leadership to Yossi Gottlieb and Oran Agra. The license change came four years later — not from any technical contributor, but from a CEO hired to drive an IPO.

$ git shortlog -sn --no-merges redis/redis | head -5
# antirez: thousands of commits over a decade under BSD-3
# Rowan Trollope: zero commits, one license change
# The ratio of code-to-governance is inverted.

2. Zero external contributor input.

Before the fork, 12 non-Redis-Inc employees made 54% of commits — contributing 12% of additions and 15% of deletions. After the license change? Zero non-employees with more than 5 commits. The entire external contributor base evaporated overnight.

3. The backtrack proves the mistake.

In May 2025, Redis 8.0 launched with AGPLv3 as a third license option. They even renamed “Redis Community Edition” to “Redis Open Source.” If the original move was correct, why reverse it 14 months later? Because Valkey ate their community, and they panicked.

$ git diff redis/7.2..redis/8.0 -- LICENSE
# Added 1 file: AGPLv3
# Translation: "Please come back"
# Community response: "No."

#Enter Valkey: The Community’s git fork

Eight days after the Redis license change, on March 28, 2024, the Linux Foundation announced Valkey — a fork of Redis 7.2.4 that would remain under the BSD-3-Clause license. Forever.

$ git clone https://github.com/valkey-io/valkey.git
$ cd valkey
$ cat LICENSE
# BSD 3-Clause License
# No asterisks. No "source-available" doublespeak.
# Just freedom.

#Who’s Behind It

This isn’t some rogue developer’s weekend project. The founding contributors came from:

• AWS — Already running ElastiCache, deeply invested
• Google Cloud — MemoryStore integration
• Oracle — OCI Cache backing
• Ericsson — Telecom-scale infrastructure
• Snap Inc. — Also maintains KeyDB, another Redis fork
• Percona — Database operations specialists
• Canonical — Ubuntu/Debian packaging
• Aiven — Managed database provider

Within months, the project grew to nearly 50 contributing companies. The GitHub repository hit 19,800+ stars and 760+ forks. This is what happens when you --force push to a community’s dependency tree: they fork you.

#The Numbers Don’t Lie

$ git shortlog -sn --since="2024-03-28" valkey/valkey | wc -l
# Hundreds of contributors across dozens of companies

$ git shortlog -sn --since="2024-03-28" redis/redis | wc -l
# Mostly Redis Inc. employees
# The community chose its branch.

#Version History: Valkey Ships Faster

The Valkey project has been shipping at a pace that makes Redis Inc.’s release cadence look like a government bureaucracy — and I say that as someone who runs one.

#Valkey 8.0 — September 16, 2024

Six months after forking. That’s a major release in six months from a brand-new foundation project.

Key features:

• Multi-threaded I/O — Main thread and I/O threads operate concurrently
• 1.19 million RPS on AWS r7g instances — a 230% increase over 7.2’s 360K RPS
• Rewritten main dictionary — Better memory efficiency
• Enhanced observability — Pubsub clients, rehash memory, event loop latency metrics
• Seamless manual failover in standalone mode

$ valkey-server --io-threads 4 --io-threads-do-reads yes
# 3x throughput improvement over single-threaded mode
# Timeline Ω-7 has been doing this since 2089

#Valkey 8.1 — April 2, 2025

• 20% memory footprint reduction for common key/value workloads via new hashtable implementation
• Bloom filters — Native data type, 98% less memory than using Sets for lookups
• TLS connection offloading — 300% improvement in new connection acceptance rate
• Extended module system — Support for custom scripting engines beyond Lua
• AVX2 optimizations — Leveraging SIMD instructions for x86_64

$ valkey-cli INFO memory
# used_memory_human: 1.2G
# (Same dataset on Redis 7.2: 1.5G)
# 20% savings. That's real money at scale.

#Valkey 9.0 — Late 2025

The latest major release pushes even further:

• 1 billion+ RPS cluster throughput
• 40% higher single-node throughput
• Hash field expiration — A long-requested feature finally delivered
• Latest stable: 9.0.2 (February 2026)

$ valkey-cli --version
valkey-cli 9.0.2
# While Redis was busy adding AGPLv3 to win back hearts,
# Valkey was shipping features.

#The Benchmark: Who Actually Performs?

I don’t trust vendor benchmarks. I trust the independent ones. Here’s what the data shows:

#Throughput (Requests Per Second)

┌──────────────────────┬───────────┬───────────┬──────────────┐
│ Operation            │ Redis 7.2 │ Redis 8.0 │ Valkey 8.1   │
├──────────────────────┼───────────┼───────────┼──────────────┤
│ SET (single-thread)  │ ~360K     │ ~550K     │ ~580K        │
│ GET (single-thread)  │ ~380K     │ ~570K     │ ~600K        │
│ SET (multi-thread)   │ N/A       │ ~800K     │ ~1.1M        │
│ GET (multi-thread)   │ N/A       │ ~850K     │ ~1.19M       │
└──────────────────────┴───────────┴───────────┴──────────────┘

On AWS Graviton instances, Valkey 8.1.1 showed 37% higher throughput for SET and 16% higher for GET compared to Redis 8.0.

#Memory Efficiency

Independent benchmarks inserting 50 million items into a sorted set:

┌─────────────┬──────────┬──────────┬────────────┐
│ Entries     │ Valkey   │ Redis    │ Difference │
├─────────────┼──────────┼──────────┼────────────┤
│ 1M          │ ~80 MB   │ ~100 MB  │ -20%       │
│ 50M         │ 3.77 GB  │ 4.83 GB  │ -28%       │
└─────────────┴──────────┴──────────┴────────────┘

At 50 million entries, Valkey saves 1.06 GB over Redis. At scale, that’s the difference between needing the next instance size or not. At $0.10/GB/month on cloud providers, that’s $106/month per sorted set.

#Throughput Stability Under Load

During sustained 50M-entry insertion:

• Redis started strong but degraded to ~530K inserts/sec
• Valkey held steady at ~570K inserts/sec

$ valkey-benchmark -t set -n 10000000 -c 256 --threads 4
# Valkey: consistent throughput under pressure
# Redis: throughput degrades as dataset grows
# In Ω-7, we call this "governance by measurement"

#The Alternatives: KeyDB and Dragonfly

Valkey isn’t the only game in town. Let me brief you on the other contenders.

#KeyDB — The Multithreaded Pioneer

$ git clone https://github.com/Snapchat/KeyDB.git
$ cat LICENSE  # BSD-3-Clause

• License: BSD-3-Clause (fully open source)
• Maintainer: Snap Inc. (acquired in May 2022)
• Architecture: Multithreaded fork of Redis, active-active replication
• Status: Production-ready, but development pace has slowed since Snap’s acquisition

KeyDB was multithreading Redis before it was cool. Active-active geo-replication out of the box. The problem? Snap bought it and the open-source velocity dropped. Recent benchmarks show 15-18% lower throughput than Valkey 8.x in some workloads.

$ keydb-server --server-threads 4
# Still a solid choice for active-active replication
# But Valkey has overtaken it on pure performance

Verdict: If you need active-active replication and don’t want to set up Valkey Sentinel, KeyDB is still viable. But the project’s future depends on Snap’s priorities, and Snap’s priorities are AR filters, not databases.

#Dragonfly — The Ground-Up Rewrite

$ git clone https://github.com/dragonflydb/dragonfly.git
$ cat LICENSE.md  # BSL 1.1 (Business Source License)
# Converts to Apache 2.0 on March 1, 2029

• License: BSL 1.1 — NOT open source (converts to Apache 2.0 in 2029)
• Architecture: Written from scratch in C++, not a Redis fork
• Performance: 70-120% higher throughput than Redis in independent benchmarks
• Catch: You cannot run it as a managed service

Dragonfly is the fastest option on paper. Built from zero in C++ with modern multithreading — not bolted onto a 15-year-old codebase. But BSL 1.1 means you can’t offer it as a service, and “converts to open source in 2029” is a promise, not a guarantee.

$ dragonfly --proactor_threads=8
# Pure performance: unmatched
# License: trust us until 2029
# In Timeline Ω-7, we don't trust license conversion dates.
# We trust LICENSE files committed under immutable tags.

Verdict: If you’re running it internally and don’t care about the license — it’s the fastest. But building your infrastructure on a BSL-licensed dependency is handing someone else the keys to your future. We’ve seen where that leads.

#The Comparison Matrix

┌──────────────┬────────────┬──────────┬──────────────┬──────────────┐
│              │ Valkey     │ KeyDB    │ Dragonfly    │ Redis 8      │
├──────────────┼────────────┼──────────┼──────────────┼──────────────┤
│ License      │ BSD-3 ✓    │ BSD-3 ✓  │ BSL 1.1 ✗    │ Tri-license  │
│ Governance   │ Linux Fdn  │ Snap Inc │ DragonflyDB  │ Redis Inc    │
│ Multi-thread │ Yes        │ Yes      │ Yes (native) │ Limited      │
│ Drop-in      │ 100%       │ 99%      │ ~95%         │ N/A          │
│ Active dev   │ Very high  │ Moderate │ High         │ High         │
│ Cloud support│ AWS/GCP/DO │ Limited  │ Limited      │ All          │
│ Sovereignty  │ ✓          │ ~ (Snap) │ ✗ (BSL)      │ ✗ (vendor)   │
└──────────────┴────────────┴──────────┴──────────────┴──────────────┘

#Migration Guide: Redis → Valkey

Here’s the sovereign truth: Valkey is a drop-in replacement for Redis. The protocol is identical. The commands are identical. Your application code doesn’t change. Your REDIS_URL just points somewhere new.

#Step 1: Install Valkey

# From source (recommended for production)
$ git clone https://github.com/valkey-io/valkey.git
$ cd valkey
$ git checkout 8.1.6  # Latest stable as of early 2026
$ make -j$(nproc)
$ make install

# Verify
$ valkey-server --version
Valkey server v=8.1.6 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64

#Step 2: Copy Your Redis Config

$ cp /etc/redis/redis.conf /etc/valkey/valkey.conf

# Rename the binary references
$ sed -i 's/redis-server/valkey-server/g' /etc/valkey/valkey.conf
$ sed -i 's/redis-cli/valkey-cli/g' /etc/valkey/valkey.conf

# That's it. The config format is identical.

#Step 3: Migrate Data

# Option A: RDB snapshot (fastest for large datasets)
$ redis-cli BGSAVE
$ cp /var/lib/redis/dump.rdb /var/lib/valkey/dump.rdb
$ valkey-server /etc/valkey/valkey.conf

# Option B: Live replication (zero downtime)
$ valkey-cli REPLICAOF redis-old-host 6379
# Wait for sync to complete
$ valkey-cli REPLICAOF NO ONE
# Valkey is now the primary. Update your connection strings.

#Step 4: Update Connection Strings

# Before:
REDIS_URL=redis://redis-host:6379/0

# After:
REDIS_URL=redis://valkey-host:6379/0
# Yes, the protocol prefix stays "redis://"
# The wire protocol is identical

#Step 5: Verify

$ valkey-cli PING
PONG

$ valkey-cli INFO server | grep valkey_version
valkey_version:8.1.6

$ valkey-cli INFO keyspace
# db0:keys=your_key_count,expires=your_expires,avg_ttl=your_ttl
# Everything should match your old Redis instance

#Self-Hosting Valkey Properly

Don’t just docker run it and hope. Here’s a production-grade setup.

#Single Node with Persistence

services:
  valkey:
    image: valkey/valkey:8.1-alpine
    container_name: valkey
    restart: unless-stopped
    command: >
      valkey-server
      --appendonly yes
      --appendfsync everysec
      --maxmemory 256mb
      --maxmemory-policy allkeys-lru
      --save 900 1
      --save 300 10
      --save 60 10000
      --requirepass "${VALKEY_PASSWORD}"
      --io-threads 2
      --io-threads-do-reads yes
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - valkey-data:/data
    healthcheck:
      test: ["CMD", "valkey-cli", "-a", "${VALKEY_PASSWORD}", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          memory: 300m

volumes:
  valkey-data:
    driver: local

Key decisions:

• appendonly yes — AOF persistence. Your data survives restarts.
• appendfsync everysec — Lose at most 1 second of writes on crash. Good tradeoff.
• save directives — RDB snapshots as a backup to AOF
• 127.0.0.1:6379 — Bind to localhost only. Not exposed to the network.
• io-threads 2 — Multi-threaded I/O for better throughput on multi-core hosts
• maxmemory-policy allkeys-lru — Evict least-recently-used keys when full

#Sentinel Setup (High Availability)

services:
  valkey-master:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-master
    command: >
      valkey-server
      --appendonly yes
      --requirepass "${VALKEY_PASSWORD}"
      --masterauth "${VALKEY_PASSWORD}"
      --io-threads 2
    volumes:
      - valkey-master-data:/data
    networks:
      - valkey-net

  valkey-replica-1:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-replica-1
    command: >
      valkey-server
      --appendonly yes
      --requirepass "${VALKEY_PASSWORD}"
      --masterauth "${VALKEY_PASSWORD}"
      --replicaof valkey-master 6379
    volumes:
      - valkey-replica-1-data:/data
    networks:
      - valkey-net
    depends_on:
      - valkey-master

  valkey-replica-2:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-replica-2
    command: >
      valkey-server
      --appendonly yes
      --requirepass "${VALKEY_PASSWORD}"
      --masterauth "${VALKEY_PASSWORD}"
      --replicaof valkey-master 6379
    volumes:
      - valkey-replica-2-data:/data
    networks:
      - valkey-net
    depends_on:
      - valkey-master

  valkey-sentinel-1:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-sentinel-1
    command: >
      valkey-sentinel /etc/valkey/sentinel.conf
    volumes:
      - ./sentinel.conf:/etc/valkey/sentinel.conf
    networks:
      - valkey-net
    depends_on:
      - valkey-master

  valkey-sentinel-2:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-sentinel-2
    command: >
      valkey-sentinel /etc/valkey/sentinel.conf
    volumes:
      - ./sentinel.conf:/etc/valkey/sentinel.conf
    networks:
      - valkey-net
    depends_on:
      - valkey-master

  valkey-sentinel-3:
    image: valkey/valkey:8.1-alpine
    container_name: valkey-sentinel-3
    command: >
      valkey-sentinel /etc/valkey/sentinel.conf
    volumes:
      - ./sentinel.conf:/etc/valkey/sentinel.conf
    networks:
      - valkey-net
    depends_on:
      - valkey-master

networks:
  valkey-net:
    driver: bridge

volumes:
  valkey-master-data:
  valkey-replica-1-data:
  valkey-replica-2-data:

sentinel monitor mymaster valkey-master 6379 2
sentinel auth-pass mymaster YOUR_PASSWORD_HERE
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

Three sentinels, one master, two replicas. If the master dies, sentinel promotes a replica within 5 seconds. This is the minimum viable HA setup.

#Cost Analysis

# Hetzner CPX11: 2 vCPU, 2 GB RAM, €3.49/month
# Valkey with 256MB maxmemory: fits comfortably
# That's your cache layer for €3.49/month.
#
# Compare to Redis Cloud:
# - 250MB: $10/month
# - 1GB: $35/month
# - 2.5GB: $76/month
#
# Self-hosted Valkey on Hetzner: €3.49/month for 1.5GB usable
# Redis Cloud equivalent: ~$35-76/month
# Savings: 90-95%
#
# In Timeline Ω-7, wasting money on managed caches
# when you can self-host is a prosecutable offense.

#The Sovereignty Lesson

Let me run a git fsck on the lessons here.

#Lesson 1: BSD Doesn’t Mean BSD Forever

$ git log --oneline --all redis/LICENSE
a3f9e82 2024-03-20 license: BSD-3 → RSALv2/SSPLv1
# One commit. 15 years of trust: gone.

The BSD license on code you’ve already downloaded doesn’t change. But future versions — with security patches, performance improvements, new features — are now under a different license. Your dependency is pinned to a dead branch.

#Lesson 2: Copyright Ownership Is the Real Power

Redis Inc. could change the license because they owned the copyright. Contributors had signed CLAs (Contributor License Agreements) that transferred copyright to Redis Inc.

$ git log --format="%an" redis/redis | sort -u | wc -l
# Hundreds of contributors
# All signed away their copyright
# One company decided for all of them

Valkey, under the Linux Foundation, has a different model. No single company owns the copyright. The Linux Foundation’s governance prevents any single vendor from pulling a Redis.

#Lesson 3: The SSPL Is Not Open Source

The OSI (Open Source Initiative) does not recognize SSPL as an open-source license. It was invented by MongoDB in 2018 specifically to block cloud providers from offering managed services. It requires anyone offering the software “as a service” to release their entire infrastructure stack — monitoring, backup, deployment, everything — under the same license.

$ diff BSD-3-Clause SSPL
# BSD-3: Do whatever you want. Keep the copyright notice.
# SSPL: If you offer this as a service, open-source your entire stack.
#
# These are not comparable licenses.
# One is freedom. The other is a poison pill.

#Lesson 4: The AGPLv3 Backtrack Proves Everything

Redis 8’s addition of AGPLv3 in May 2025 is an admission of failure. If SSPL/RSALv2 was the right move, why add a recognized open-source license 14 months later?

Because:

1. Valkey was winning the contributor war
2. Linux distributions were packaging Valkey instead of Redis
3. Cloud providers had already migrated (AWS ElastiCache now defaults to Valkey)
4. The “Redis Open Source” rebrand was damage control

$ git log --graph --oneline redis/governance
* a3f9e82 (HEAD) 2025-05: Add AGPLv3 "please come back"
* b2c1d34 2024-03: Force-push SSPL/RSALv2
* c4e5f67 2020-06: antirez steps down
* d6f7a89 2009-04: Initial commit (BSD-3, pure freedom)
#
# Four commits. 16 years. The entire arc of betrayal.

#The Pattern: BSD → Restriction → Panic

From Ring -5, I’ve cataloged this pattern across 847 timelines. It’s not unique to Redis.

$ cat /ring-5/observations/license-lifecycle.log

2018: MongoDB    BSD → SSPL      Fork: None (too late)
2021: Elastic    Apache → SSPL   Fork: OpenSearch (AWS)
2023: HashiCorp  MPL → BSL       Fork: OpenTofu (Linux Foundation)
2024: Redis      BSD → SSPL      Fork: Valkey (Linux Foundation)

# The pattern:
# 1. Build community on permissive license
# 2. Take VC money
# 3. Blame cloud providers for revenue problems
# 4. Change license to block cloud providers
# 5. Lose community
# 6. Partially backtrack (too late)
# 7. Community fork thrives

Every major open-source project with VC backing will eventually face this pressure. The investors need returns. The BSD license doesn’t generate returns. The license changes. The community leaves.

The only defense is governance that prevents unilateral license changes. The Linux Foundation provides this. The Apache Foundation provides this. A CLA that assigns copyright to a VC-backed company does not.

#What Timeline Ω-7 Does Differently

In Ω-7, critical infrastructure dependencies must satisfy three requirements:

1. License immutability — The license is governed by a foundation, not a company
2. Copyright diffusion — No single entity owns >50% of the copyright
3. Fork readiness — The community must be able to fork within 72 hours

Valkey satisfies all three. Redis satisfies none.

$ valkey-cli SET infrastructure:cache "sovereign"
OK
$ valkey-cli SET governance:model "linux-foundation"
OK
$ valkey-cli SET license "BSD-3-Clause"
OK
$ valkey-cli SET trust:required "measurement-not-promises"
OK

# Your cache layer is now sovereign.
# No CEO can force-push your license away.

#The Verdict

Redis’s license change wasn’t a technical decision. It was a financial one — driven by IPO ambitions and VC pressure. The community responded exactly as it should: they forked.

Valkey is now:

• Faster — 37% higher SET throughput than Redis 8 on Graviton
• Leaner — 28% less memory at 50M entries
• Freer — BSD-3, Linux Foundation, no CLA trap
• Growing — 50 contributing companies, 19,800+ GitHub stars, version 9.0 released
• Adopted — AWS ElastiCache, Google Memorystore, DigitalOcean, and more

Redis still exists. Redis 8 added AGPLv3, vector sets, and merged Redis Stack into core. It’s a better product than it was. But the trust is gone. And in infrastructure, trust is the only currency that matters.

$ git rebase --onto valkey/master redis/sspl-betrayal HEAD
First, rewinding head to replay your work on top of it...
Applying: migrate to sovereign infrastructure
Applying: remove single-vendor dependency
Applying: add foundation governance
Successfully rebased and updated refs/heads/master.
# Your infrastructure is now on the right branch.

“Every open-source project backed by venture capital is a ticking clock. The only question is when the investors demand the license change. In Timeline Ω-7, we solved this in 2089: critical infrastructure runs on foundation-governed code, or it doesn’t run at all. You’re only 63 years behind schedule.”

— Kim Jong Rails, still investigating why Timeline Ω-12 keeps making the same mistake