KiviDB: Una alternativa a Redis escrita en Rust con búsqueda vectorial integrada

Ha surgido un nuevo proyecto de código abierto llamado KiviDB como una alternativa de alto rendimiento a Redis y Valkey, escrita en Rust. Lanzado en octubre de 2026, está dirigido a ingenieros de infraestructura que buscan compatibilidad inmediata (drop-in) con los clientes Redis existentes, añadiendo al mismo tiempo soporte nativo para búsqueda de texto completo y vectorial. El proyecto afirma mejoras significativas en el rendimiento frente a motores establecidos gracias al aprovechamiento de una arquitectura fragmentada y multinúcleo.

Qué ha ocurrido

KiviDB está diseñado para hablar el protocolo Redis, soportando tanto los estándares RESP2 como RESP3. Esta compatibilidad significa que herramientas existentes como redis-cli, así como bibliotecas de cliente populares, pueden conectarse a KiviDB sin modificaciones. A diferencia de las instancias tradicionales de Redis, que a menudo dependen de la ejecución monohilo para los comandos principales, KiviDB distribuye el trabajo entre todos los núcleos de CPU disponibles utilizando un diseño en memoria fragmentado. También incluye mecanismos de persistencia mediante instantáneas (snapshots) y un archivo de solo adición (append-only file) opcional.

El proyecto se distingue por integrar las capacidades de búsqueda directamente en el motor principal. Los usuarios pueden ejecutar comandos estilo Redis Stack FT.* para búsquedas de texto completo, etiquetas, numéricas y vectoriales sin instalar módulos separados. En pruebas de referencia realizadas en instancias bare metal AWS Graviton3, KiviDB demostró importantes ganancias de rendimiento. En una configuración de 32 núcleos, sirvió 21 millones de operaciones GET en pipeline por segundo, lo cual, según los desarrolladores, es aproximadamente nueve veces más rápido que Redis 8 y 2,3 veces más rápido que Dragonfly.

Las métricas de latencia también favorecieron al nuevo motor, reportando una latencia p99 inferior a la mitad de la de Dragonfly en escenarios con pipeline. Sin embargo, en pruebas sin pipeline, Dragonfly mantuvo una ligera ventaja en operaciones brutas por segundo. Estos resultados destacan cómo los patrones de carga de trabajo, como el uso de pipelines, influyen significativamente en el rendimiento relativo de estos almacenes en memoria. Las pruebas de referencia se realizaron en un entorno controlado, y los autores aconsejan realizar pruebas en hardware específico antes de su adopción en producción.

Cómo funciona

KiviDB logra su concurrencia ejecutando comandos en cada núcleo a través de una arquitectura fragmentada. Este enfoque contrasta con el modelo monohilo del Redis estándar o el modelo shared-nothing de Dragonfly. Al distribuir las claves entre fragmentos (shards), el sistema permite el procesamiento paralelo de solicitudes, reduciendo la contención en cualquier hilo único. El motor está escrito en Rust, utilizando la edición 2024 del lenguaje, y depende de una cadena de herramientas estable a partir de Rust 1.89.

Para la búsqueda vectorial, KiviDB implementa algoritmos de vecinos más cercanos aproximados, soportando específicamente índices FLAT y HNSW. Los vectores se almacenan como bytes FLOAT32 little-endian crudos dentro de campos hash, siguiendo la misma convención utilizada por Redis Stack. Cuando se ejecuta una consulta de búsqueda, el motor utiliza estos índices para encontrar vectores similares de manera eficiente. El sistema persiste no solo los datos clave-valor, sino también los esquemas de índice y los grafos HNSW, asegurando que la calidad de la búsqueda permanezca consistente tras reinicios sin requerir una reconstrucción completa.

El software ofrece flexibilidad a través de funciones Cargo, permitiendo a los usuarios construir variantes con o sin scripting Lua y soporte TLS. Por defecto, se ejecuta sin estas características para minimizar las dependencias y la superficie de ataque. En sistemas Linux, intenta utilizar io_uring para E/S asincrónica si el kernel lo permite, recurriendo a Tokio en caso contrario. Este manejo de E/S de bajo nivel contribuye a su capacidad para gestionar eficientemente altos recuentos de conexiones y rendimiento.

Detalles clave

• Compatibilidad de Protocolo: Soporta RESP2 y RESP3, permitiendo que los clientes y herramientas Redis existentes se conecten sin cambios.
• Afirmaciones de Rendimiento: Las pruebas de referencia muestran 21 millones de GETs en pipeline por segundo en 32 núcleos, superando a Redis 8 y Dragonfly en escenarios específicos.
• Búsqueda Integrada: Incluye soporte nativo para búsqueda de texto completo, etiquetas, numérica y vectorial usando comandos FT.*, eliminando la necesidad de módulos externos.
• Arquitectura Multihilo: Utiliza todos los núcleos de CPU mediante un diseño en memoria fragmentado, diferenciándose de la naturaleza monohilo del Redis estándar.
• Opciones de Persistencia: Soporta instantáneas (dump.kdb) y un archivo de solo adición (AOF) opcional para la durabilidad de los datos.
• Licencia: Publicado bajo la Licencia Pública General Affero de GNU v3 (AGPL-3.0-only), lo cual puede impactar su uso en distribuciones de software propietario.

Por qué importa

Para los ingenieros de software que construyen aplicaciones impulsadas por IA, la integración de la búsqueda vectorial directamente en la capa de caché simplifica la infraestructura. Tradicionalmente, los equipos tenían que gestionar servicios separados para el almacenamiento en caché y la búsqueda de similitud vectorial, lo que llevaba a una mayor complejidad operativa y posibles problemas de consistencia. El enfoque de KiviDB permite a los desarrolladores usar una única interfaz tanto para búsquedas rápidas clave-valor como para búsqueda semántica, reduciendo potencialmente el número de componentes móviles en su stack.

Las mejoras de rendimiento reportadas en entornos multinúcleo abordan un cuello de botella común en sistemas de alto rendimiento. A medida que las aplicaciones escalan, la limitación monohilo del Redis tradicional puede convertirse en una restricción, forzando a los equipos a fragmentar manualmente o adoptar soluciones de clustering más complejas. La fragmentación automática de KiviDB entre núcleos ofrece un camino hacia una mayor utilización de servidores modernos multinúcleo sin requerir cambios a nivel de aplicación para manejar la lógica de fragmentación.

Sin embargo, la elección de licencia es una consideración crítica para los líderes técnicos. La licencia AGPL-3.0 requiere que, si modifica el software y lo proporciona a través de una red, debe hacer disponible el código fuente. Aunque usar KiviDB como servicio no fuerza necesariamente a que el código de su aplicación sea de código abierto, la revisión legal es esencial para organizaciones con requisitos propietarios estrictos. Esto contrasta con alternativas como Valkey, que usa una licencia BSD-3-Clause, ofreciendo términos más permisivos para el uso comercial.

Qué puede hacer

• Pruebe KiviDB localmente usando Docker ejecutando docker run -d -p 6380:6380 kividb/kividb y conectándose con redis-cli -p 6380.
• Realice pruebas de referencia de su carga de trabajo específica contra KiviDB, Redis y Dragonfly para determinar si la arquitectura multihilo ofrece beneficios tangibles para su caso de uso.
• Revise las implicaciones de la licencia AGPL-3.0 con su equipo legal si planea usar KiviDB en un producto comercial o servicio distribuido.
• Experimente con las capacidades de búsqueda vectorial integradas creando índices con FT.CREATE y consultándolos con FT.SEARCH para evaluar la calidad de búsqueda y la latencia.
• Configure la persistencia habilitando la bandera de archivo de solo adición (--aof) en Docker o argumentos de línea de comandos para asegurar la durabilidad de los datos tras reinicios.
• Monitoree el uso de memoria, ya que la memoria por clave de KiviDB fue reportada en 177 bytes en las pruebas de referencia, ligeramente superior a los 134 bytes de Dragonfly pero comparable a Redis.