KeyDB: A Redis Fork With Multi-Threading

Redis Had a License Tantrum. Here’s What Forked Off.

In March 2024, Redis Ltd. dropped the Apache 2.0 license and switched to a dual SSPL/RSALv2 model. If you’re not familiar with SSPL, it’s the license MongoDB invented specifically to annoy cloud providers — and it worked, because it also annoys everyone else. The community response was predictable: forks everywhere.

Valkey emerged as the most organized response — backed by AWS, Google, Oracle, and the Linux Foundation, it’s essentially the community continuing Redis 7.x development under BSD. It has real momentum in 2026 and is probably where you should look if you just want “Redis, but not the drama.”

But KeyDB predates all of this. It’s been forking around since 2019, when a startup called EQ Alpha (later acquired by Snap) decided Redis’s single-threaded event loop was a problem worth solving. They were right. They solved it. Then Snap acquired them, and things got… quieter.

Let’s dig into what KeyDB actually is, where it still makes sense, and when you should pick Valkey instead.

What KeyDB Is and Where It Came From

KeyDB forked from Redis 6.2.x and immediately went in a different direction: multi-threaded I/O from day one. Redis’s event loop is famously single-threaded — great for simplicity and predictable latency, but it means a single Redis instance maxes out at roughly one CPU core’s worth of throughput. On modern hardware with 16+ cores, that’s a lot of silicon sitting idle.

KeyDB replaced the single-threaded event loop with a multi-threaded one. Multiple threads handle I/O, with careful locking to maintain data consistency. The headline claim was 2-4x throughput improvement on multi-core hardware without changing a single line of your application code.

They also added two other features that Redis still doesn’t have (or didn’t until much later):

• Active Replication — both nodes accept writes and replicate to each other bidirectionally. Redis replica nodes are read-only by default and always will be.
• FLASH backend — store your hot data in RAM, let warm/cold data spill to NVMe. If you’ve got 64GB of data but only 16GB of RAM, this is interesting.

Snap acquired EQ Alpha in 2022, which is where the “somewhat stagnant” reputation comes from. Development slowed. The GitHub repo still gets commits, but it’s not the same pace as 2019-2021. In 2026, KeyDB is actively maintained but not actively innovated. It tracks Redis 6.2.x features, not Redis 7.x.

Architecture: The Multi-Threaded Event Loop

The core change in KeyDB is the server-threads configuration option. By default it’s set to 2, but you can push it up to match your physical core count.

# keydb.conf
server-threads 4
server-thread-affinity true

server-thread-affinity pins threads to specific CPU cores, which reduces context-switching overhead. On a dedicated cache server with 8 cores, setting server-threads 4 (leaving headroom for OS and other processes) gets you close to the throughput ceiling.

The important caveat: this helps I/O-bound workloads. If your bottleneck is compute (big Lua scripts, complex sorted set operations), you’ll see less gain. If you’re doing thousands of simple GET/SET operations per second from many parallel clients, you’ll see a lot.

Active Replication

This is the genuinely unique feature. Regular Redis replication is primary-replica: the primary accepts writes, replicas are read-only. If your primary dies, you fail over. During failover, you’re down.

KeyDB’s active replication is bidirectional:

# keydb.conf — on both nodes
active-replica yes
replicaof <peer-ip> 6379

Both nodes accept writes. Both nodes replicate to each other. If one goes down, the other keeps accepting reads and writes. When the down node comes back, it catches up automatically.

The tradeoff is eventual consistency. Conflicting writes (same key, different values, written to different nodes at the same moment) resolve via last-writer-wins based on timestamp. If you’re using KeyDB as a cache where the latest value is always the right value, this is fine. If you’re using it as a distributed counter or a job queue where every write matters, it is absolutely not fine.

Multi-Master

You can extend active replication to N nodes, not just 2:

# node-c keydb.conf
active-replica yes
replicaof node-a 6379
replicaof node-b 6379

Every node replicates from every other node. This is multi-master. It works. It has the same eventual-consistency caveats at N times the complexity. For most homelabbers, 2-node active-active is the sweet spot.

FLASH Backend

KeyDB FLASH lets you use NVMe as an extension of RAM:

storage-provider flash /mnt/nvme/keydb-flash

Hot keys stay in RAM. Keys that haven’t been accessed recently get evicted to the NVMe store. Reads from NVMe are slower than RAM, but faster than re-fetching from your database. If you have a dataset that’s 10x larger than your available RAM and you’re on fast NVMe, this is worth evaluating. Otherwise, it adds complexity for marginal gain.

Getting It Running: Docker Compose, 2-Node Active-Active

Here’s a working 2-node active-active KeyDB setup. This assumes you’re running both nodes on the same Tailscale network and have hostnames keydb-a and keydb-b resolving between them. Adjust IPs to match your setup.

# docker-compose.yml — run on BOTH nodes with node-specific keydb.conf

services:
  keydb:
    image: eqalpha/keydb:latest
    container_name: keydb
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - ./keydb.conf:/etc/keydb/keydb.conf
      - keydb-data:/data
    command: keydb-server /etc/keydb/keydb.conf

volumes:
  keydb-data:

keydb.conf on node-a (replace keydb-b-tailscale-ip with the actual Tailscale IP):

# keydb.conf — node-a
bind 0.0.0.0
port 6379
server-threads 2
server-thread-affinity true

# Active replication
active-replica yes
replicaof 100.x.y.z 6379

# Persistence
appendonly yes
appendfilename "appendonly.aof"

# Optional: require auth
# requirepass yourpasswordhere

keydb.conf on node-b (point back at node-a’s Tailscale IP):

# keydb.conf — node-b
bind 0.0.0.0
port 6379
server-threads 2
server-thread-affinity true

active-replica yes
replicaof 100.a.b.c 6379

appendonly yes
appendfilename "appendonly.aof"

Bring both up, then verify:

# On node-a
docker exec -it keydb keydb-cli INFO replication

You should see role:active-replica and the peer listed as a connected replica. Write to node-a, read from node-b — it should be there within milliseconds.

Benchmarks: What You Actually Get

KeyDB ships with keydb-benchmark, a drop-in replacement for redis-benchmark. The numbers below are representative of what you’d see on a 4-core VM with server-threads 2 vs a stock Redis 7.2 instance on identical hardware.

# KeyDB benchmark — 100k requests, 50 parallel clients, pipelining 16
keydb-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -P 16 -t get,set

# Redis benchmark — same params
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -P 16 -t get,set

Rough output comparison (your numbers will vary):

KeyDB (server-threads 2):
  SET: ~420,000 ops/sec
  GET: ~480,000 ops/sec

Redis 7.2 (single-threaded):
  SET: ~210,000 ops/sec
  GET: ~250,000 ops/sec

At 50 parallel clients with pipelining, KeyDB wins by roughly 2x. The gap narrows as you reduce client concurrency — at 1 client, no pipeline, Redis and KeyDB perform similarly because the single client can’t saturate either server.

The sweet spot for KeyDB is high concurrency, I/O-bound GET/SET workloads. That’s exactly the profile of a session cache, a rate limiter, or an API response cache under load.

Where KeyDB Loses Ground

Against Redis 7.4

Redis added multi-threaded I/O in version 6.0 (for clients) and continued improving it in 7.x. By Redis 7.4, the performance gap between Redis and KeyDB on raw throughput is much smaller than it was in 2019 when KeyDB launched. If raw ops/sec is your only concern, Redis 7.4 or Valkey 8.x might get you there without running a fork.

Redis still doesn’t have active replication, though. If that’s your use case, KeyDB is still the only game in town.

Against Valkey

Valkey 8.x is what happens when actual Redis maintainers fork the project with Linux Foundation backing. It tracks Redis 7.x features, gets security patches promptly, has a real governance model, and in 2026 is being adopted as the default Redis replacement in many Linux distros.

KeyDB’s development tracks Redis 6.2.x. That’s not ancient, but it means you’re missing:

• Redis 7.x LMPOP / LPOS / OBJECT FREQ
• Listpack encoding improvements (memory efficiency)
• Function-based scripting (replacing Lua EVALSHA for complex operations)
• Better multi-exec transaction semantics in 7.4

If your app uses any Redis 7.x features, KeyDB can’t run it. Valkey can.

Valkey also doesn’t have active replication, which means it’s still primary-replica only. For an HA cache where you want both nodes to accept writes, Valkey doesn’t help you. KeyDB does.

Picking the Right Tool

Here’s the honest decision tree:

Use KeyDB when:

• You need active-active (bidirectional) replication and eventual consistency is acceptable
• You’re running a high-concurrency cache on multi-core hardware and Redis’s single-threaded event loop is your actual bottleneck
• You have a large warm dataset and NVMe to burn (FLASH backend)
• You’re on Redis 6.2.x-compatible commands and don’t need 7.x features

Use Valkey when:

• You want a drop-in Redis replacement with an actual community and roadmap
• You need Redis 7.x features
• You’re running a general-purpose cache, pub/sub bus, or session store
• You want to be on the side of history here — Valkey is where the ecosystem is moving

Use managed Redis (ElastiCache, Upstash, Redis Cloud) when:

• You’re building something that matters in production and don’t want to babysit replication at 2 AM
• Ops cost is more valuable than infra cost
• You want Redis 7.x with actual SLAs

Don’t use any of them for strong consistency. If you need “this write definitely landed before this read,” use Postgres. Your cache is not your database.

The Bottom Line

KeyDB is a clever piece of engineering that solved a real problem (Redis’s single-threaded ceiling) years before Redis got around to it. The active-active replication feature is still genuinely unique and useful — no other Redis-compatible store lets both nodes accept writes and stay in sync bidirectionally.

The tradeoffs are real: eventual consistency on conflicting writes, a codebase that’s based on Redis 6.2.x in a world that’s moved to 7.x, and a development pace that’s slowed since the Snap acquisition. It’s not abandoned — you can still file an issue and get a response — but it’s not exactly thriving either.

For a home lab cache that needs to survive a node dying without a failover dance, 2-node active-active KeyDB on Tailscale is a legitimately good setup. Set server-threads to match your core count, leave active-replica yes on both nodes, and you’ve got a cache that reads and writes from either node without any client-side logic.

For anything greenfield where you’re choosing a Redis-compatible store from scratch, Valkey is the better default. It has the community, the roadmap, and the distro adoption that KeyDB doesn’t. KeyDB’s window was 2019-2023. Valkey owns the next decade.

Use the right fork for the right job. Your 2 AM on-call rotation will appreciate the distinction.

Related Reading

• Dragonfly vs Redis: Single-Binary Performance
• Adding NOT NULL on a Big Table Without Downtime
• ClickHouse vs DuckDB vs StarRocks: Light OLAP
• DuckDB for Local Analytics: Pandas on Steroids
• NocoDB DB Management System