{"id":1722,"date":"2026-09-23T12:49:53","date_gmt":"2026-09-23T15:49:53","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/?p=1722"},"modified":"2026-09-23T12:49:53","modified_gmt":"2026-09-23T15:49:53","slug":"keydb-fork-multithread-do-redis","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2026\/09\/keydb-fork-multithread-do-redis\/","title":{"rendered":"KeyDB: the multithreaded Redis fork, tested on 2026"},"content":{"rendered":"

\"Mascote<\/p>\n

KeyDB was born with a simple promise: take Redis, which executes commands on a single thread, and make it use all the cores on the machine. It worked, became a product, was acquired by Snap, and gained features Redis never had, such as active replication between two masters and member expiration within a set. The catch is that in September 2026 the latest KeyDB version is almost three years old. Before putting KeyDB into production, it's worth knowing what it does well, what breaks, and where the project stands. This post installs, configures, replicates, and benchmarks KeyDB in containers, and ends with a recommendation.<\/p>\n

Where KeyDB came from<\/h2>\n

KeyDB started in early 2019 as an experiment by John Sully<\/strong> and Ben Schermel<\/strong>, in Toronto, to add multithreading to Redis. The project grew, went through Y Combinator (2020 summer batch) and became EQ Alpha Technology, which maintained two editions: the open one and KeyDB Pro, closed and paid.<\/p>\n

In 12 May 2022<\/strong> KeyDB announced that it became part of Snap<\/a>, owner of Snapchat. With the acquisition, the code from the Pro edition was opened and version 6.3.0 merged everything into a single project under the BSD-3-Clause<\/strong>. license. The repository moved from EQ-Alpha\/KeyDB<\/code> to Snapchat\/KeyDB<\/a>, and Snap began using KeyDB in part of its own cache layer.<\/p>\n

The stated reason for the fork is in the README: the authors felt that Redis prioritized code simplicity over simplicity for the user, who ended up needing external components (Sentinel, proxies, scripts) to solve common problems. KeyDB wanted to be Redis \u201cwith batteries included\u201d, maintaining compatibility with the protocol, modules, and Lua scripts.<\/p>\n

How the multithreaded architecture works<\/h2>\n

The classic Redis executes all commands on a main thread. Since version 6 it can use io-threads<\/code> to read and write to sockets in parallel, but command execution remains serialized. KeyDB went another way: it runs the entire event loop on multiple threads<\/strong>. Each connection is assigned to a thread on accept()<\/code>, and parsing and network I\/O happen in parallel. Access to the key table is protected by a spinlock<\/strong>, and transactions hold that lock for the entire duration of the EXEC<\/code>, which preserves the atomicity that applications expect from Redis (the authors' explanation<\/a>).<\/p>\n

In practice, this is controlled by two directives in the keydb.conf<\/code>:<\/p>\n

server-threads 4              # threads que atendem clientes (padr\u00e3o do pacote: 2)\nserver-thread-affinity true   # fixa cada thread num n\u00facleo<\/code><\/pre>\n
The README recommends relating server-threads<\/code> to the number of NIC queues, not to the number of cores, and suggests 4 as a starting point: because KeyDB uses spinlocks, too many threads increase lock contention. In the benchmark below, 8 threads still performed better than 4 with 6 cores dedicated to the server, so measure on your own hardware.<\/p>\n
The diagram shows the two nodes used in this post's lab, each with four threads, and active replication between them:<\/p>\n
\"Diagrama<\/figure>\n
Features Redis does not have<\/h2>\n
According to Oracle's official documentation<\/a>, KeyDB adds to Redis' feature set:<\/p>\n