Presentamos HotKV

HotKV es un almacén de datos multihilo y compatible con Redis, escrito desde cero en C++ moderno, creado para sacar la máxima velocidad a los servidores modernos con muchos núcleos al menor costo posible. Soy Norbert E. Boros, fundador y CEO de HotKV Ltd. Este artículo explica por qué lo creé, qué hace hoy y qué resultados obtuvo en las mediciones.

En resumen. HotKV ejecuta comandos en muchos hilos a la vez dentro de un solo proceso y habla RESP2 y RESP3, el protocolo de Redis. En nuestro benchmark de octubre de 2026 con una sola instancia en 160 vCPUs, tuvo el mayor throughput en 11 de los 12 comandos que medimos, y Dragonfly quedó a la par en el duodécimo. La configuración y sus límites se describen más abajo.

Por qué creé HotKV

La velocidad me importa en todo lo que construyo. Un sitio web, una herramienta o un servidor deberían responder al instante, y cuando no lo hacen, quiero saber por qué. Ese hábito ha marcado mi trabajo desde que escribo software.

C y C++ son mis lenguajes principales desde hace muchos años. Durante casi diez años trabajé en software anticheat para videojuegos que se ejecutaba en los PC de miles de jugadores. Tenía que analizar la memoria en busca de trampas usando la menor cantidad posible de CPU y de memoria, porque cada ciclo que consumía se le quitaba al juego. Ese trabajo me enseñó a medirlo todo, a diseñar en función del hardware y a tratar el bajo consumo de recursos como una característica por derecho propio.

Paralelamente, usé Redis y Valkey en muchos proyectos que necesitaban una caché rápida: almacenes de sesiones, listas de direcciones IP bloqueadas por un firewall y una caché delante de cientos de millones de registros de SQL Server. Son herramientas excelentes. También despertaron mi curiosidad por saber qué podría hacer un almacén clave-valor diseñado desde el principio para los servidores con muchos núcleos que usamos hoy.

HotKV es la respuesta a la que llegué. Lo escribí desde cero en C++ moderno para sacar del hardware la mayor velocidad posible, al menor costo posible. El benchmark de abajo muestra dónde está hoy, y espero que aún quede margen de mejora.

El costo de la IA

Hubo una segunda razón. Ejecutar aplicaciones de IA se estaba volviendo caro, para mí y, a juzgar por lo que compartían otros desarrolladores en internet, también para muchos más. Una gran parte de ese costo suele venir de enviar a un modelo preguntas que ya ha respondido. Un almacén rápido que reconoce una pregunta repetida o similar y la responde desde la caché es una de las formas más directas de reducir esa factura. Por eso la caché para cargas de trabajo de IA es una parte central de HotKV.

Para qué sirve HotKV

HotKV Ltd existe para que este tipo de software ofrezca más rendimiento y sea más asequible. Los servidores modernos tienen muchos núcleos y un almacén de datos debería aprovecharlos, de modo que obtengas la mayor velocidad posible al menor costo posible.

La segunda idea es mantener más piezas del stack en un solo lugar. Los equipos que desarrollan sobre LLM suelen terminar ejecutando una caché, una base de datos vectorial y algún sitio donde guardar la memoria de los agentes, con un montón de código de enlace entre ellos. Quiero que la caché y el trabajo de IA construido a su alrededor vivan en un solo motor, junto a tus datos: caché exacta y semántica de las llamadas a modelos, búsqueda vectorial, memoria de agentes y presupuestos de tokens. Menos sistemas que ejecutar debería significar menos piezas móviles y una factura menor. La página de IA enumera lo que hay disponible hoy, y el benchmark de ahorro de tokens muestra lo que ahorró la caché de las llamadas a modelos en nuestra prueba.

HotKV mantiene el protocolo de Redis y las bibliotecas de cliente habituales.

El problema

Un único hilo de ejecución de comandos puede convertirse en un cuello de botella en una máquina con muchos núcleos. Un almacén de datos construido en torno a un solo hilo de ejecución suele aprovechar el resto de la máquina ejecutando varias instancias o un clúster, y eso conlleva decisiones de despliegue y trabajo operativo. Quería que HotKV partiera del extremo opuesto, con los comandos ejecutándose de forma concurrente dentro de una sola instancia, para que un único proceso pueda aprovechar toda la máquina.

Qué hace HotKV de forma diferente

HotKV™ está escrito en C++20 y diseñado para ejecutar comandos en muchos núcleos a la vez, de modo que una sola instancia pueda aprovechar una máquina entera. Dragonfly, que medimos más abajo, también adopta un enfoque multihilo.

• Muchos núcleos, una instancia. Los comandos se ejecutan de forma concurrente en los núcleos de la máquina, de modo que una instancia puede aprovechar un servidor grande en lugar de varios más pequeños.
• Clientes y protocolo conocidos. HotKV admite RESP2 y RESP3, por lo que las bibliotecas de cliente habituales pueden conectarse a él. Se admiten las transacciones (MULTI/EXEC) y los scripts en Lua. Consulta la documentación de los comandos para ver los comandos admitidos y las diferencias que haya.

Cómo se construye y se prueba

Construyo HotKV yo mismo y uso asistencia de IA donde ayuda. Lo que importa más que cómo se escribió una línea es si resiste, así que el motor se prueba a fondo. Tiene más de 2000 pruebas automatizadas y se compila con AddressSanitizer, ThreadSanitizer y UndefinedBehaviorSanitizer. También tiene objetivos de fuzzing para el parser del protocolo, el despacho de comandos, la carga de RDB y AOF, el flujo de replicación y el bus del clúster.

La configuración del benchmark, sus límites y los resultados completos están en la página de Rendimiento, para que puedas juzgar las cifras por tu cuenta.

Instantánea del benchmark

Actualizado en octubre de 2026: las cifras publicadas originalmente en este artículo procedían de ejecuciones del benchmark que más tarde descubrimos que eran defectuosas (entre otras cosas, todos los generadores de carga usaban la misma semilla aleatoria), por lo que las sustituimos por los resultados de nuestro benchmark reconstruido.

Octubre de 2026: HotKV, Redis, Valkey y Dragonfly

HotKV Ltd realizó este benchmark. Medimos HotKV, compilado desde el código fuente, frente a Redis 8.10.2, Valkey 9.1.2 y Dragonfly 2.0.2. Cada servidor se ejecutó solo, como una única instancia en las 160 vCPUs de una máquina Azure D160alds_v7 (AMD EPYC 9V45), con la persistencia desactivada. Tres máquinas independientes de 64 vCPUs generaron la carga con memtier_benchmark: valores de 256 bytes, una profundidad de pipeline de 30 y 5.000.000 de claves cargadas previamente. Cada cifra es la mediana de tres ejecuciones de 10 segundos.

HotKV tuvo el mayor throughput en 11 de los 12 comandos. Frente a Redis o Valkey midió entre 8,6 y al menos 69,7 veces su throughput, según el comando y el servidor; frente a Dragonfly, entre 1,97 y 4,41 veces en esos 11 comandos, varias de ellas cotas inferiores. En PING, Dragonfly midió un 0,6 % por delante. Lo contamos como un empate, porque los generadores de carga estaban cerca de su propio límite. La cifra más alta en un comando de datos fue de 90,8 millones de operaciones INCR por segundo. INCR y PING mueven pocos datos y están limitados por los generadores de carga, por lo que la cifra propia de HotKV en ellos podría ser mayor.

Cómo leer la tabla

MGET lee ocho claves y MSET escribe cuatro pares clave-valor por comando, y el throughput cuenta comandos. El informe marca siete cifras de HotKV (GET y seis comandos de escritura) porque alcanzaron su umbral de uso de red del 85 %, y PING porque los generadores de carga superaron el 85 % de CPU. Las relaciones calculadas a partir de ellas son cotas inferiores, marcadas con ≥. GET y PING son los límites reales. En los seis comandos de escritura, la cifra de uso de red del informe suma el tráfico entrante y el saliente y la compara con el tope de salida, por lo que exagera lo cerca que estuvieron de un límite. El más pesado, SETNX, usó como máximo cerca del 80 % del techo de entrada medido. Mantenemos el ≥ en ellos como convención conservadora. Las tablas completas, las marcas y las notas del método están en la página de Rendimiento.

Alcance del benchmark

• Compilación y ajuste. HotKV se compiló con -march=native para la CPU de la prueba, mientras que los demás servidores eran sus compilaciones de versión estándar.
• Ajustes de hilos. Cada servidor recibió todos los núcleos de la máquina: HotKV --threads 160, Dragonfly 160 hilos proactor, Valkey io-threads 160 y Redis io-threads 128, su máximo. Redis y Valkey ejecutan los comandos en un solo hilo y podrían alcanzar un mayor throughput con menos hilos de E/S, por lo que sus cifras pueden estar por debajo de su mejor resultado. No ejecutamos clústeres ni varias instancias de ellos.
• Alcance. Doce comandos, un tamaño de valor, una profundidad de pipeline, sin TLS y sin persistencia. No se midieron LPOP ni RPOP, porque a estas velocidades una lectura destructiva vacía en 10 segundos cualquier lista que quepa en memoria. El informe registra la latencia y el uso de memoria, pero aquí no los comparamos. Los servidores hicieron cantidades de trabajo muy distintas en cada ejecución de 10 segundos, por lo que las cifras de memoria no son comparables en igualdad de condiciones. No se midieron cargas de trabajo mixtas.
• Variación. Redis varió mucho entre sus tres ejecuciones en varios comandos, hasta 7,2 veces entre su ejecución más rápida y la más lenta en HSET, y la mediana lo oculta. Si se compara con la ejecución más rápida de cada competidor en lugar de con su mediana, HotKV siguió liderando los 11 comandos.

Redis, Valkey y Dragonfly son marcas comerciales de sus respectivos propietarios. Se nombran únicamente para identificar el software que medimos, y esto no implica patrocinio, respaldo ni afiliación.

Qué incluye hoy

Las familias de comandos principales incluyen cadenas, listas, conjuntos, hashes, conjuntos ordenados, streams, índices geoespaciales, mapas de bits, HyperLogLog, pub/sub y scripts en Lua. Los módulos de IA y las funciones enterprise funcionan en planes con licencia. Los precios detallan lo que incluye cada plan. Consulta la documentación para ver la cobertura de comandos actual. Además del conjunto de comandos de Redis:

• Etiquetado de claves: etiqueta las claves con etiquetas arbitrarias y consulta por etiqueta (TAG.SET, TAG.MEMBERS y cinco comandos más).
• TTL en nanosegundos: NEXPIRE, NTTL y NEXPIREAT establecen y leen la caducidad en nanosegundos, de modo que los plazos pueden ser más finos que un milisegundo. Las claves caducadas se recuperan mediante un barrido en segundo plano y cuando se accede a ellas.
• Compresión opcional de valores: para valores por encima de un umbral de tamaño (512 bytes por defecto), desactivada salvo que la actives.
• Snapshots sin fork: BGSAVE escribe en un hilo en segundo plano en lugar de en un proceso bifurcado. Un snapshot no es una copia en un instante concreto. Cada clave se guarda tal como estaba cuando el snapshot llegó a ella. La reescritura del archivo append-only sí usa fork.
• Métricas de Prometheus: un endpoint HTTP integrado, desactivado por defecto y que se activa con metrics-port, por lo que no hace falta ningún exportador externo.

HotKV también incluye búsqueda vectorial integrada con índices HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). La medimos frente a Redis 8 en Búsqueda vectorial: HotKV frente a los vector sets de Redis 8, de 1 a 100 clientes.

Empieza en HotKV Cloud, o habla con ventas para ejecutar HotKV en tus propios servidores.