KeyDB: el fork multihilo de Redis, probado en 2026

KeyDB nació con una promesa sencilla: tomar Redis, que ejecuta los comandos en un único hilo, y hacer que use todos los núcleos de la máquina. Funcionó, se convirtió en producto, fue comprado por Snap y ganó características que Redis nunca tuvo, como la replicación activa entre dos maestros y la expiración de miembros dentro de un conjunto. Sin embargo, en septiembre de 2026 la última versión de KeyDB tiene casi tres años. Antes de poner KeyDB en producción, conviene saber qué hace bien, qué se rompe y en qué estado está el proyecto. Este post instala, configura, replica y mide KeyDB en contenedores, y termina con una recomendación.

De dónde vino KeyDB

KeyDB empezó a principios de 2019 como un experimento de John Sully e Ben Schermel, en Toronto, para añadir multithreading a Redis. El proyecto creció, pasó por Y Combinator (promoción del verano de 2020) y se convirtió en la empresa EQ Alpha Technology, que mantenía dos ediciones: la abierta y KeyDB Pro, cerrada y de pago.

En 12 de mayo de 2022 KeyDB anunció que pasaba a formar parte de Snap, propietaria de Snapchat. Con la compra, el código de la edición Pro se abrió y la versión 6.3.0 fusionó todo en un único proyecto bajo licencia BSD-3-Clause. El repositorio pasó de EQ-Alpha/KeyDB para Snapchat/KeyDB, y Snap comenzó a utilizar KeyDB en parte de su propia capa de caché.

El motivo declarado del fork está en el README: los autores consideraban que Redis priorizaba la simplicidad del código sobre la simplicidad para el usuario, que terminaba necesitando componentes externos (Sentinel, proxies, scripts) para resolver problemas comunes. KeyDB quiso ser el Redis “con todo incluido”, manteniendo compatibilidad con el protocolo, los módulos y los scripts de Lua.

Cómo funciona la arquitectura multihilo

El Redis clásico ejecuta todos los comandos en un hilo principal. Desde la versión 6 puede usar io-threads para leer y escribir en los sockets en paralelo, pero la ejecución de los comandos sigue siendo serializada. KeyDB fue por otro camino: ejecuta el bucle de eventos completo en varios hilos. Cada conexión se asigna a un hilo en el accept(), y el parsing y la E/S de red ocurren en paralelo. El acceso a la tabla de claves está protegido por un spinlock, y las transacciones mantienen ese bloqueo durante todo el EXEC, lo que preserva la atomicidad que las aplicaciones esperan de Redis (explicación de los autores).

En la práctica, esto se controla mediante dos directivas en el keydb.conf:

server-threads 4              # threads que atendem clientes (padrão do pacote: 2)
server-thread-affinity true   # fixa cada thread num núcleo

El README recomienda relacionar server-threads al número de colas de la placa de red, no al número de núcleos, y sugiere 4 como punto de partida: como KeyDB usa spinlocks, demasiados hilos aumentan la contención por el lock. En el benchmark más abajo, 8 hilos aún rindieron más que 4 con 6 núcleos dedicados al servidor, así que mide en tu propio hardware.

El diagrama muestra los dos nodos usados en el laboratorio de este post, cada uno con cuatro hilos, y la replicación activa entre ellos:

Características que Redis no tiene

Según la documentación oficial, KeyDB añade al conjunto de funcionalidades de Redis:

• Replicación activa (active-replica): dos o más nodos son réplicas entre sí y aceptan lectura y escritura al mismo tiempo. No hay promoción de réplica ni Sentinel en el failover; basta con un balanceador TCP que apunte a los nodos sanos. Con varios nodos en malla, la funcionalidad se convierte en multi-master. La documentación promete que, tras una división de red, “la escritura más reciente gana” (last write wins). En las pruebas de abajo, esto no ocurrió.
• Subkey expires: el comando EXPIREMEMBER da TTL a un miembro de set, hash o sorted set, no a la clave entera. En Redis, esta funcionalidad solo llegó en la versión 7.4, y únicamente para campos de hash.
• MVCC: a documentación describe instantáneas que permiten ejecutar KEYS e SCAN sin bloquear la base de datos, y un background save sin fork(), que evita la duplicación de páginas de memoria durante la instantánea.
• FLASH storage: con storage-provider flash /caminho, KeyDB lo escribe todo en un RocksDB en SSD/NVMe y mantiene en RAM solo los datos calientes. La propia documentación clasifica la función como beta/experimental.
• Copia de seguridad directa a S3 con db-s3-object, y ModJS, un módulo para escribir comandos en JavaScript sobre V8.

La situación del proyecto en septiembre de 2026

Consulté GitHub, Docker Hub y el repositorio APT del proyecto el 23 de septiembre de 2026:

Indicador	Situación
Última release	v6.3.4, publicada el 30/10/2023
Último commit en la rama main	abril de 2024 (ajustes de build)
Imagen Docker eqalpha/keydb:latest	6.3.4 de 30/10/2023, base Ubuntu 20.04
Repositorio APT	Ubuntu 20.04/22.04 y Debian 11/12; sin Ubuntu 24.04 ni Debian 13
Issues abiertas	292
Base de código	Redis 6.2 (el propio servidor se anuncia como redis_version:6.3.4)

En 31 de enero de 2025, John Sully, autor principal de KeyDB, publicó una issue de despedida: era su último día en Snap, no sabía qué haría la empresa con el proyecto y sugirió que el esfuerzo de desarrollo migrase al Valkey, que, en sus pruebas, ya había alcanzado el rendimiento de KeyDB. Desde entonces, la issue “¿Está KeyDB abandonada por Snap Inc?” sigue sin respuesta de ningún mantenedor.

El dato más grave es el de seguridad. La CVE-2025-49844 (CVSS 9.9 en el NVD) es un use-after-free en Lua que permite ejecución remota de código por un usuario autenticado, y según el NVD afecta a “todas las versiones de Redis con scripting Lua”. KeyDB heredó ese código. El PR que移植 la corrección está abierto desde octubre de 2025: recibió aprobaciones de usuarios de la comunidad, pero ningún mantenedor hizo el merge.

Conclusión honesta: KeyDB está parada. El repositorio no se ha archivado y Snap puede seguir usando una versión interna, pero el proyecto público no recibe releases, correcciones de seguridad ni paquetes para las distribuciones actuales.

Instalación en Ubuntu y Debian

El proyecto mantiene un repositorio APT propio. Probé el procedimiento en contenedores con systemd y funcionó en Ubuntu 22.04 y en Debian 12:

echo "deb https://download.keydb.dev/open-source-dist $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/keydb.list
sudo wget -O /etc/apt/trusted.gpg.d/keydb.gpg \
  https://download.keydb.dev/open-source-dist/keyring.gpg
sudo apt update
sudo apt install keydb
sudo systemctl enable --now keydb-server

El paquete keydb instala el keydb-server (servicio systemd ejecutándose como usuario keydb, configuración en /etc/keydb/keydb.conf) y el keydb-tools (keydb-cli, keydb-benchmark, keydb-check-aof e keydb-check-rdb). Para revisar los comandos del servicio, consulta Dominando systemd.

systemctl is-active keydb-server
# active
keydb-cli ping
# PONG
keydb-cli set curso linuxpro && keydb-cli get curso
# OK
# "linuxpro"

En el Ubuntu 24.04 y en Debian 13, el apt update falla porque el repositorio no tiene las suites noble e trixie. En Ubuntu 24.04, cambiar $(lsb_release -sc) por jammy instaló y levantó el servicio sin errores en mi prueba. Esto es un workaround, no soporte oficial, y Debian 13 sigue sin paquete (hay una issue pidiendo, sin respuesta).

Ejecutándolo con Docker

La imagen oficial es eqalpha/keydb. de Redis protected-mode no y ninguna contraseña en la keydb.conf predeterminada, así que nunca publiques el puerto sin configurar autenticación. Una instancia mínima, solo en localhost y con contraseña:

docker run -d --name keydb \
  -p 127.0.0.1:6379:6379 \
  -v keydb-data:/data \
  eqalpha/keydb:x86_64_v6.3.4 \
  keydb-server /etc/keydb/keydb.conf \
    --requirepass 'TroqueEstaSenha' \
    --server-threads 4 \
    --appendonly yes

docker exec -it keydb keydb-cli -a 'TroqueEstaSenha' ping

Cualquier cliente Redis funciona sin cambios, incluido redis-cli y las bibliotecas de los lenguajes, porque el protocolo es el mismo. Si todavía no usas contenedores en el día a día, la historia de Docker explica de dónde viene la herramienta.

Replicación activa entre dos nodos

El laboratorio utiliza dos contenedores, keydb-lab-a e keydb-lab-b, en una red Docker. Cada nodo apunta al otro con replicaof y activa active-replica:

# keydb-a.conf  (no keydb-b.conf, troque para: replicaof keydb-lab-a 6379)
port 6379
bind 0.0.0.0
protected-mode yes
requirepass SenhaForte123
masterauth SenhaForte123
server-threads 4
active-replica yes
replicaof keydb-lab-b 6379
appendonly yes
dir /data

docker network create keydb-lab-net
for n in a b; do
  docker run -d --name keydb-lab-$n --network keydb-lab-net \
    -v $PWD/keydb-$n.conf:/etc/keydb/keydb.conf:ro \
    eqalpha/keydb:x86_64_v6.3.4 keydb-server /etc/keydb/keydb.conf
done

A="docker exec keydb-lab-a keydb-cli -a SenhaForte123 --no-auth-warning"
B="docker exec keydb-lab-b keydb-cli -a SenhaForte123 --no-auth-warning"

$A info replication | grep -E 'role|link_status'
# role:active-replica
# master_global_link_status:up
# master_link_status:up

$A set site linuxpro.com.br ; $B get site     # "linuxpro.com.br"
$B set autor nilton         ; $A get autor    # "nilton"

El registro confirma los cuatro hilos (Thread 0 alive hasta Thread 3 alive) y el aviso de que active-replica yes implica replica-read-only no. Escrituras hechas en cualquier nodo aparecieron en el otro en menos de un segundo.

También funcionó el escenario que la documentación destaca: con el nodo B detenido, grabé un valor nuevo en A. Al volver a encender B, se sincronizó y pasó a mostrar el valor nuevo, sin sobrescribir A con el dato antiguo de su AOF.

La prueba de partición de red

Después simulé una partición de red. Bajé el repl-timeout durante 5 segundos, desconecté el nodo B de la red Docker y esperé a que el master_link_status pasara a down. Con los nodos aislados, grabé la misma clave en ambos y reconecté B:

$A config set repl-timeout 5 ; $B config set repl-timeout 5
docker network disconnect keydb-lab-net keydb-lab-b
# ... aguarda master_link_status:down em B ...
$B set k6 azul-antigo      # escrita mais velha, em B
$A set k6 verde-novo       # escrita mais nova, em A (2 s depois)
docker network connect keydb-lab-net keydb-lab-b
# ... aguarda master_link_status:up ...
$A get k6    # "azul-antigo"
$B get k6    # "verde-novo"

En lugar de converger hacia la escritura más reciente, los nodos intercambiaron los valores y quedaron divergentes. El log mostró una resincronización parcial (Successful partial resynchronization), y cada nodo aplicó por encima la escritura del otro. Repetí la prueba siete veces, con particiones de 3 a 15 segundos, tanto con el enlace de replicación cayendo como sin llegar a caer, y el resultado fue siempre el mismo. La divergencia continuó hasta que un docker restart keydb-lab-b forzó una sincronización completa, y entonces los dos nodos quedaron con azul-antigo: la escritura más reciente se perdió.

El comportamiento es conocido. La issue #366 relata el mismo problema desde septiembre de 2021, y en diciembre de 2023 otro usuario confirmó que continuaba en la 6.3.4. Como la replicación activa es la principal razón para elegir KeyDB, esto pesa: no use active-replica donde una divergencia silenciosa de datos sea inaceptable.

Expiración de miembros con EXPIREMEMBER

Esta función funcionó como se documenta, incluso replicada al otro nodo:

$A sadd sessoes u1 u2 u3
$A expiremember sessoes u1 3          # u1 expira em 3 s
$A ttl sessoes                        # -1: a chave em si não expira
sleep 4
$A smembers sessoes                   # u2, u3
$B smembers sessoes                   # u2, u3

$A hset carrinho item1 a item2 b
$A expiremember carrinho item1 2000 ms   # unidade opcional: s ou ms

Para cachés con etiquetas o listas de sesiones, esto evita el truco de mantener un sorted set paralelo solo para controlar la validez de cada miembro.

Benchmark sencillo: KeyDB, Valkey y Redis

El README de KeyDB advierte que los keydb-benchmark y el redis-benchmark son demasiado lentos para saturar un servidor multihilo y recomienda el memtier_benchmark. Fue lo que usé, en contenedores en la misma máquina.

Entorno: AMD Ryzen 9 9900X (12 núcleos/24 hilos), 186 GB de RAM, Docker en red bridge. El servidor quedó fijado a 6 núcleos físicos (--cpuset-cpus 0-5,12-17) y memtier a los otros 6 (6-11,18-23), sin compartir núcleo. Sin persistencia (--save "" --appendonly no), 200 mil claves de 100 bytes precargadas, 8 hilos × 50 conexiones en memtier, 1 SET por cada 10 GETs, claves aleatorias, 20 segundos por ronda. Hice tres rondas por configuración, y la tabla muestra la mediana. La máquina ejecutaba otros contenedores al mismo tiempo, así que compare las filas entre sí, no con cifras de otros entornos.

docker run --rm --network keydb-lab-net --cpuset-cpus 6-11,18-23 \
  redislabs/memtier_benchmark:latest -s keydb-lab-srv -p 6379 \
  --protocol=redis --threads=8 --clients=50 --ratio=1:10 \
  --data-size=100 --key-maximum=200000 --key-pattern=R:R \
  --test-time=20 --hide-histogram

Servidor y configuración	ops/s (mediana)	latencia media	p99
KeyDB 6.3.4, server-threads 1	213 mil	1,88 ms	2,78 ms
Valkey 9.1.2, io-threads 1	214 mil	1,86 ms	3,81 ms
KeyDB 6.3.4, server-threads 4	833 mil	0,48 ms	1,01 ms
Valkey 9.1.2, io-threads 4	633 mil	0,63 ms	1,01 ms
KeyDB 6.3.4, server-threads 8	1,30 millón	0,31 ms	0,81 ms
Valkey 9.1.2, io-threads 8	1,25 millón	0,32 ms	0,58 ms
Redis 8.10.2, io-threads 8	1,28 millón	0,31 ms	0,65 ms

Qué muestran los números:

• Con un hilo, KeyDB y Valkey empatan, lo cual tiene sentido: es esencialmente el mismo motor heredado de Redis.
• Con 4 hilos, KeyDB queda aproximadamente un 30% por delante de Valkey. Ejecutar comandos en varios hilos todavía rinde más cuando hay pocos hilos.
• Con 8 hilos, los tres quedan a menos de un 4% entre sí, y Valkey y Redis tienen el p99 más bajo. En ese punto, el límite probablemente sea el propio memtier o la pila de red de Docker, y ya no el servidor.

En resumen, la ventaja de rendimiento que justificaba a KeyDB en 2019 hoy es pequeña, y solo aparece con pocos hilos. Esto coincide con lo que el propio John Sully escribió al salir de Snap.

Redis vs Valkey vs KeyDB

Datos cotejados en los repositorios oficiales en 23/09/2026:

	Redis	Valkey	KeyDB
Licencia	triple desde la 8.0: RSALv2, SSPLv1 o AGPLv3 (7.4 era solo RSALv2/SSPL)	BSD-3-Clause	BSD-3-Clause
Quién lo mantiene	Redis Ltd.	comunidad, bajo la Linux Foundation	Snap (sin actividad pública)
Última versión estable	8.10.2 (17/09/2026)	9.1.2 (01/09/2026)	6.3.4 (30/10/2023)
Base de código	propia	fork del último Redis BSD (serie 7.2)	fork de Redis 6.2
Multihilo	hilos de I/O; comandos en un hilo	hilos de I/O; comandos en un hilo	event loop y comandos en varios hilos
Cluster con sharding	sim	sim	sí (modo cluster de Redis 6.2)
Replicación multi-master	no en la edición open source	no	sí, con el bug de divergencia mencionado
Expiración por miembro	campos de hash (desde 7.4)	campos de hash (desde 9.0)	set, hash y sorted set
Corrección de la CVE-2025-49844	sí (8.2.2 y backports)	sim	no

El cambio de licencia de Redis se anunció el 20 de marzo de 2024. La Linux Foundation lanzó Valkey el 28 de marzo de 2024 a partir del último código BSD, y el 1 de mayo de 2025 Redis 8 añadió AGPLv3 como tercera opción, volviendo a tener una licencia aprobada por la OSI.

Un cuidado con las comparaciones que circulan por internet: hay artículos que atribuyen a KeyDB la licencia Apache 2.0 (la licencia es BSD-3-Clause) y tablas de rendimiento sin entorno ni método descritos. Compruébalo siempre en el repositorio y mide en tu hardware.

Cuál elegir

• Proyecto nuevo: usa Valkey. Es BSD, tiene lanzamientos frecuentes, parches de seguridad, paquetes en las distribuciones actuales y es la alternativa recomendada por el propio autor de KeyDB. Con io-threads este ya aprovecha varios núcleos.
• ¿Necesita el ecosistema de Redis Ltd. (módulos integrados de Redis 8, soporte comercial)? Utilice Redis, teniendo en cuenta que la licencia es AGPLv3 o source-available.
• ¿Ya tiene KeyDB en producción? Planifique la migración a Valkey. Mientras no se lleve a cabo, bloquee los scripts Lua para quien no los necesite (ACL SETUSER <usuario> -@scripting, que probé en 6.3.4), no exponga el puerto fuera de la red interna y trate la replicación activa como susceptible a divergencias. EXPIREMEMBER y la replicación activa no existen en Valkey, así que revise el código que utiliza esas funciones.
• KeyDB en un proyecto nuevo: no lo recomiendo. El rendimiento que lo justificaba ha quedado atrás, y la falta de mantenimiento pesa más.

Conclusión

KeyDB demostró una tesis: una caché compatible con Redis podía utilizar todos los núcleos, y esa presión ayudó a empujar a Redis y a Valkey hacia el multihilo de E/S. Pero una base de datos sin mantenedor, sin parche para una RCE crítica y con replicación activa que pierde escrituras tras una partición no debe recibir datos nuevos en 2026. Para quien necesite alta disponibilidad, el camino es Valkey, y el post Valkey en clúster muestra cómo montar tres primarios y tres réplicas, con failover probado. Si el caché va a producción, monitorízalo de verdad, con Prometheus y Node Exporter o con un comprobador simple como el Go Uptime. Y si tu aplicación en Go ya usa Redis para colas, el post sobre Asynq funciona igual con Valkey.