snapchat/keydb

★ 12,475C++Audience · ops devopsComplexity · 3/5Setup · moderate

Mindmap

mindmap
  root((KeyDB))
    What it does
      Multi-threaded Redis
      Drop-in replacement
      Higher throughput
    Extra Features
      Active replication
      FLASH storage
      SubKey expiry
    Tech Stack
      C++
      Redis protocol
    Use Cases
      High-speed caching
      High availability
      Large dataset caching

mindmap root((KeyDB)) What it does Multi-threaded Redis Drop-in replacement Higher throughput Extra Features Active replication FLASH storage SubKey expiry Tech Stack C++ Redis protocol Use Cases High-speed caching High availability Large dataset caching

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Replace Redis with KeyDB on the same hardware to get higher throughput without changing any application code.

USE CASE 2

Set up active-active replication where two KeyDB instances both accept writes simultaneously for high availability.

USE CASE 3

Use FLASH storage to let a cache dataset spill from RAM to local SSD when data exceeds available memory.

USE CASE 4

Run expensive full key scans without blocking other operations thanks to KeyDB's concurrent read architecture.

Tech stack

C++

Getting it running

Difficulty · moderate Time to first run · 30min

Configured via Redis-style config files with additional thread-count options, existing Redis config files work without changes.

In plain English

KeyDB is a modified version of Redis, a widely used in-memory data store that applications use to cache information and handle fast lookups. The core change KeyDB makes is adding multithreading: where Redis processes requests one at a time on a single thread, KeyDB can process many requests at once across multiple CPU cores. According to the README's benchmark charts, this allows KeyDB to handle significantly more operations per second on the same hardware. Because KeyDB keeps full compatibility with the Redis protocol, commands, modules, and scripts, it is designed to work as a drop-in replacement. An application using Redis can switch to KeyDB without changing any code. Features like atomic transactions and scripts behave the same way. KeyDB adds several capabilities that go beyond Redis. Active Replication lets two KeyDB instances stay in sync while both accept reads and writes at the same time, which simplifies certain high-availability setups. FLASH Storage allows data that does not fit in RAM to spill over to a local SSD. Subkey Expires lets you set expiry times on individual fields inside a data structure, not just on a whole key. The MVCC architecture (a way of managing concurrent reads and writes) means expensive commands like full key scans do not block other operations. The project is maintained by Snap Inc. (the company behind Snapchat), which uses KeyDB internally as part of its caching infrastructure. There is no separate commercial product and no paid support. The README links to community Slack, a forum, and GitHub issues for help. Configuration is handled through the same style of file Redis uses, with a few new options added to control thread count, client balancing across threads, and S3 backup.

Copy-paste prompts

Prompt 1

I'm running Redis and want to switch to KeyDB for better multi-core performance. What's the migration process and which config options should I set for multi-threading?

Prompt 2

Set up active replication between two KeyDB instances so both can accept writes at the same time. Give me the config file settings I need.

Prompt 3

My KeyDB dataset is larger than my available RAM. Show me how to configure FLASH storage to spill overflow data to SSD.

Prompt 4

I want to set expiry times on individual fields inside a Redis hash using KeyDB's SubKey Expires feature. Show me the exact commands.

Open on GitHub → Explain another repo

← snapchat on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.