cloudparts

KeyDBDormant

A multithreaded fork of Redis, owned by Snap, that serves one dataset from several threads and adds active-active replication and an experimental flash tier.

What it is
Key-value stores
Used for
Caching
Part of
Fork of Redis
Type
Open source
Made by
Snap Inc.
License
BSD-3-Clause
Status
Dormant. Last release 6.3.4 in October 2023 and last commit to main in April 2024; keydb.dev now only points to the docs repository on GitHub.
Facts checked
24 October 2026
Website Source code

What it is

KeyDB began in 2019 as a fork of Redis by developers who wanted it to use more than one CPU core. It runs the normal Redis event loop on several threads (server-threads); each client connection is pinned to a thread when it is accepted, and access to the shared hash table is guarded by a spinlock, held for the length of EXEC in a transaction. It speaks the Redis protocol and runs Redis modules and Lua scripts, so clients and tools work unchanged, and an MVCC design lets commands such as KEYS and SCAN run without blocking the rest of the database.

It adds features Redis doesn’t have. With active-replica yes, a replica also accepts writes, and two servers can be replicas of each other; every write is timestamped and, after a broken link heals, the newest write wins. More than two masters must be fully meshed, or data is lost. KeyDB on FLASH, built on RocksDB and still labelled experimental, writes all data to SSD and keeps hot keys in RAM, so a dataset can outgrow memory.

Snap, which already ran KeyDB in its caching infrastructure, took it over in 2021 and in May 2022 released the formerly paid Pro and Enterprise features as one BSD-3-Clause project, version 6.3.0. There is no commercial edition or paid support. Activity has since slowed: 6.3.4 in October 2023 is the latest release, the main branch last changed in April 2024, and both keydb.dev and docs.keydb.dev now just redirect to the KeyDB-docs repository. Valkey is the actively maintained BSD-licensed Redis fork.

Why teams pick it

  • Several threads on one node, so one server can use more cores without sharding
  • A drop-in replacement for Redis: same protocol, modules and scripts
  • Active-active replication between two nodes, with the newest write winning after a split
  • BSD-3-Clause, with the former enterprise features included

Watch out for

  • Little development since 2024: no release since October 2023 and no paid support
  • Its 6.3 releases track Redis 6-era behaviour, so commands and fixes added to Redis and Valkey since are missing
  • Active replication resolves conflicts by timestamp, so concurrent writes to the same key on two masters lose one of them
  • The flash tier is still marked experimental

Specs

Compare with alternatives →
Data model
Redis data structures under keys
Query language
Redis commands, Lua scripts and modules
Client protocol
Redis protocol
Replication
Redis replication, plus active-active replicas where the newest write wins
Storage engine
In memory; experimental FLASH tier on RocksDB
Ways to run it
Self-hosted

More of the Redis family

What all key-value stores have in common →Compare side by side →
ValkeyOpen sourceThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.RedisOpen sourceAn in-memory data-structure server: the default cache, and also queues, counters and leaderboards.+1 KeyDB

How it fits with other technologies

keydb.conf for two servers that replicate to each other · text

# on server A (10.0.0.1); server B mirrors this with replicaof 10.0.0.1
server-threads 4            # threads serving clients
active-replica yes          # this replica also accepts writes
replicaof 10.0.0.2 6379     # replicate from B, while B replicates from A

# optional: keep the dataset on SSD, hot keys in RAM (experimental)
# storage-provider flash /var/lib/keydb-flash

See it in a real stack

No architecture uses KeyDB yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2024

Redis runs its commands on a single event loop, which keeps its code simple but leaves most of a big server’s cores idle. In 2019 its developers forked it as KeyDB with a different philosophy: Redis, they argued, kept the code simple “at the expense of complexity for the user”, who then had to run clusters and Sentinel to use more hardware. KeyDB took on the harder code so a single node could do more, and added active replication and a flash storage tier, some of them in paid Pro and Enterprise editions.

Snap used KeyDB in its caching infrastructure and took the project over in 2021. In May 2022 it open-sourced everything as one BSD-3-Clause project with release 6.3.0. Releases continued until 6.3.4 in October 2023; commits to the main branch stopped in April 2024, By then the Linux Foundation had forked Redis as Valkey, also BSD-licensed, after Redis changed its licence in 2024.

Why it’s built this way

Run the Redis event loop on several threads
Users wanted more throughput from one machine without sharding. Pinning each connection to a thread and guarding the shared hash table with a short spinlock kept most of Redis’s code and semantics.
Let replicas accept writes
With active replication a hot spare is already writable, so failover needs no promotion step; timestamps decide which write wins after a split.
Open-source the enterprise features at Snap
Once Snap owned it, there was no paid product to protect, so the project merged both editions into one BSD-licensed codebase.

Timeline

  1. 2019

    KeyDB forks Redis to add multithreading

  2. 2021

    KeyDB joins Snap Inc.

  3. 2022

    Version 6.3.0 open-sources the former enterprise features under BSD-3-Clause

  4. 2023

    Release 6.3.4 in October, the latest so far

  5. 2024

    Last commit to the main branch, in April

Sources4 · facts checked 24 October 2026

Improve this page on GitHub