KiviDB es una alternativa de alto rendimiento y multihilo a Redis y Valkey, desarrollada en el lenguaje de programación Rust. Diseñada como un reemplazo directo, es compatible con el protocolo Redis (RESP2 y RESP3), lo que le permite funcionar perfectamente con clientes, bibliotecas y la herramienta `redis-cli` existentes. A diferencia del Redis estándar, que tradicionalmente opera en un bucle de ejecución de comandos de un solo hilo, KiviDB utiliza un diseño de clave-valor en memoria fragmentado donde los comandos se ejecutan en todos los núcleos, con el objetivo de maximizar la utilización del hardware.
La imagen sirve como recurso visual principal para la identidad del proyecto y sus características principales como una alternativa a Redis basada en Rust.
La base de datos se distingue por integrar capacidades de búsqueda avanzadas directamente en su núcleo. Soporta comandos de estilo Redis Stack `FT.*` para búsqueda de texto completo (usando BM25), etiquetas, numéricos y búsqueda vectorial (usando algoritmos FLAT o HNSW). Esta integración permite a los usuarios realizar búsquedas de vecinos más cercanos aproximados (ANN) por vector en campos hash sin requerir módulos separados o motores de consulta externos. Para la persistencia, KiviDB emplea instantáneas nativas y un archivo de solo anexión (AOF) opcional. Una característica notable de su sistema de instantáneas es que preserva el gráfico HNSW de cada campo vectorial, asegurando que la calidad de la búsqueda se mantenga constante inmediatamente después de un reinicio sin requerir una reconstrucción completa del índice.
Este gráfico respalda la discusión sobre las capacidades de búsqueda vectorial integradas de KiviDB y los algoritmos ANN.
Las pruebas de rendimiento proporcionadas por los desarrolladores sugieren ventajas significativas de rendimiento sobre sus competidores establecidos. En pruebas realizadas en hardware AWS Graviton3, KiviDB informó servir 21 millones de GETs en tubería por segundo en 32 núcleos, lo que los desarrolladores afirman es aproximadamente 9 veces más rápido que Redis 8 y 2.3 veces más rápido que Dragonfly. Sin embargo, estas cifras representan un entorno controlado específico y pueden variar según el hardware, la carga de trabajo y la configuración. Si bien KiviDB ofrece una alternativa de alto rendimiento con capacidades vectoriales integradas, los usuarios deben considerar las implicaciones de su licencia AGPL-3.0 y las características de rendimiento específicas de su arquitectura fragmentada en comparación con los modelos de nada compartido utilizados por otras alternativas multihilo como Dragonfly.
Este gráfico ilustra las ventajas de rendimiento específicas mencionadas en la sección de pruebas de rendimiento.
KiviDB proporciona varias opciones de configuración, incluida la capacidad de activar el scripting en Lua y el soporte TLS a través de características de Cargo. También admite varias políticas de expulsión y límites de memoria. Para el despliegue, ofrece imágenes de Docker tanto para arquitecturas `amd64` como `arm64`, y puede ejecutarse junto a una instancia estándar de Redis escuchando en el puerto 6380 por defecto. El proyecto es de código abierto bajo la Licencia Pública General GNU Affero v3, e incluye soporte tanto para `io_uring` como para `Tokio` como modelos de E/S dependiendo de las capacidades del kernel de Linux subyacente.
Una consideración técnica para los usuarios es el comportamiento de la base de datos durante la reconstrucción de índices. Si bien el gráfico HNSW se persiste en las instantáneas, si ocurre un reinicio desde un archivo de solo anexión (AOF) en lugar de una instantánea, el sistema puede necesitar reconstruir los índices de búsqueda a partir de los hashes brutos. Durante este período, la mayoría de los comandos devolverán un estado `LOADING`, aunque los comandos básicos como `PING` e `INFO` siguen siendo funcionales. Esta distinción resalta la importancia de realizar instantáneas regulares para mantener una alta disponibilidad en cargas de trabajo con mucha búsqueda.
Además, las afirmaciones de rendimiento del proyecto han generado debate sobre las metodologías de evaluación. Algunos observadores señalan que, dado que Redis utiliza multihilo para operaciones de E/S, compararlo con una arquitectura multihilo como KiviDB requiere una consideración cuidadosa de la inanición del grupo de hilos y la fijación de núcleos. Si bien la arquitectura de KiviDB está diseñada para minimizar la contención de bloqueos mediante bloqueos de grano fino, las ganancias de rendimiento práctico en escenarios del mundo real —donde la distribución de datos y los patrones de acceso varían— siguen siendo un área clave para la verificación independiente.