KiviDB: la base de datos en Rust que supera a Redis 9 veces

Qué es KiviDB y por qué le importa a quien paga la factura de Redis

KiviDB es una base de datos en memoria escrita en Rust que se presenta como alternativa directa a Redis y Valkey. Su apuesta central: es multihilo y reparte el trabajo entre todos los núcleos del servidor, mientras que Redis ejecuta los comandos en un solo hilo (con hilos de I/O como apoyo).

El detalle que suele decidir una migración es otro: KiviDB habla el protocolo de Redis (RESP2 y RESP3). Eso significa que los clientes existentes, redis-cli y las librerías que ya usas funcionan sin cambios. Escucha en el puerto 6380, no en el 6379, así que puedes levantar ambos motores en paralelo y comparar antes de comprometerte.

La versión actual es la 1.1.0 y se distribuye bajo licencia AGPL-3.0-only, con una licencia comercial disponible para organizaciones que no pueden usar AGPL.

Los números: 21 millones de GET por segundo

El dato que sostiene el anuncio es concreto. En una sesión de benchmarks de octubre de 2026 sobre AWS Graviton3 (c7gn.metal, 64 vCPU limitados a 32 núcleos), KiviDB reporta:

• 21,2 millones de GET/s con pipeline 16, frente a 9,1M de Dragonfly 2.0.2, 2,4M de Redis 8.10 y 4,7M de un Redis Cluster de 32 shards.
• 19,2 millones de SET/s en la misma prueba, contra 8,5M de Dragonfly y 2,0M de Redis.
• Latencia p99 de 0,36 ms en GET y 0,42 ms en SET con pipeline, menos de la mitad que Dragonfly (0,88 / 1,07 ms) y muy por debajo de Redis (2,2 / 2,7 ms).

Hay un matiz que el propio repositorio reconoce y que conviene leer antes de emocionarse: sin pipeline, Dragonfly gana. KiviDB registra 3,07M de GET/s frente a 3,35M de Dragonfly. La ventaja grande aparece cuando el cliente agrupa comandos, que es el patrón típico de un caché de alta concurrencia pero no el de todas las aplicaciones.

También hay un costo en memoria: 177 bytes por clave frente a 134 bytes de Dragonfly. Redis queda en 178 bytes, así que KiviDB empata con el incumbente y pierde contra el competidor más eficiente.

Búsqueda vectorial integrada: el ángulo para proyectos de IA

La segunda promesa es la que más puede mover la aguja para equipos que construyen con IA. KiviDB implementa comandos FT.* compatibles con Redis Stack, con búsqueda de texto completo (BM25), filtros por tag y numéricos, y búsqueda vectorial ANN en modo FLAT o HNSW.

En la prueba sobre glove-25-angular (1,18 millones de vectores, 25 dimensiones, HNSW con M=16 y EF_CONSTRUCTION=256), KiviDB reporta 59.300 consultas por segundo con recall@10 de 0,943 en ef 64, frente a 41.300 de Dragonfly y 31.800 de Redis 8.10. En recall más alto la ventaja se invierte: en ef 512, Dragonfly alcanza 29.800 consultas/s contra 18.700 de KiviDB, aunque KiviDB logra mejor recall (0,998 contra 0,995).

El punto débil está en la ingesta: 31 segundos para construir el índice, contra 13 segundos de Dragonfly y 38 de Redis. Y después de ingerir, KiviDB ocupa 1,66 GB frente a 1,13 GB de Dragonfly y 1,07 GB de Redis.

La contrapartida interesante es la persistencia: los snapshots nativos (dump.kdb) guardan las claves, los esquemas de índice y, si ejecutas SAVE o BGSAVE con los índices poblados, también el grafo HNSW. Eso evita reconstruir el índice al reiniciar, un problema clásico en despliegues vectoriales.

¿Qué significa esto para tu startup?

1. Mide en tu hardware antes de migrar. El propio repositorio lo advierte: los resultados dependen del entorno y deben tratarse como una captura controlada, no como una garantía. Si tu cuello de botella es latencia p99 en un caché con pipeline, vale la pena un benchmark propio. Si tu carga es de comandos sueltos y secuenciales, la ventaja desaparece y el costo de migrar no se justifica.

2. Revisa la licencia antes de que legal la revise por ti. AGPL-3.0 es OSI-approved, pero muchas organizaciones la tienen vetada por política interna. El repositorio aclara que usar KiviDB no pone tu aplicación bajo AGPL: tu código se conecta por red y no es una obra derivada. La obligación aparece solo si modificas KiviDB y lo ofreces como servicio. Si tu empresa prohíbe AGPL de plano, existe una licencia comercial.

3. Aprovecha el puerto 6380 para una prueba de bajo riesgo. Levantar KiviDB junto a tu Redis actual no rompe nada. Puedes apuntar un cliente secundario al 6380, correr tu carga real y comparar sin tocar producción.

4. Si evalúas búsqueda vectorial, pesa la ingesta. La ventaja en consultas es real, pero 31 segundos de construcción de índice frente a 13 de Dragonfly importa si reindexas con frecuencia. Para un índice que se construye una vez y se consulta miles de veces, el balance cambia.

El contexto: un mercado que se está reordenando

KiviDB no aparece en el vacío. El cambio de licencia de Redis en 2024 abrió la puerta a alternativas, y el ecosistema se movió rápido. En octubre de 2026, Percona anunció Valkey-proxy, un proyecto open source bajo licencia BSD-3-Clause que busca facilitar la migración empresarial desde Redis hacia Valkey, con disponibilidad general prevista para principios de 2027.

En el anuncio, Kyle Davis, General Manager for Valkey en Percona, resumió el problema que enfrentan los equipos: las empresas que quieren migrar se quedan en "Redis comercial, que es caro de licenciar y operar", o pasan a un servicio gestionado de un proveedor de nube cuyos proxies no son open source.

Ese es el terreno donde KiviDB compite. No solo contra Redis, sino contra Dragonfly, Valkey, KeyDB y los servicios gestionados de los grandes proveedores. Su diferenciador no es el precio ni la comunidad —el repositorio acumula 139 estrellas y 2 forks, números modestos— sino el rendimiento medido y la búsqueda vectorial integrada sin módulos aparte.

Conclusión

KiviDB es un proyecto joven con números llamativos y una arquitectura coherente: Rust, sharding por núcleo, compatibilidad RESP y búsqueda vectorial en el mismo binario. Para un founder construyendo infraestructura de IA, la combinación de caché y búsqueda vectorial en un solo motor es atractiva porque elimina un componente de la arquitectura.

Pero conviene leer los benchmarks con la misma disciplina con la que leerías los de cualquier proveedor. La ventaja es enorme con pipeline y se estrecha sin él; la memoria por clave es competitiva pero no líder; y la ingesta vectorial es más lenta que la de Dragonfly. La decisión correcta no sale de esta nota: sale de correr tu propia carga en tu propio hardware.

Fuentes

• KiviDB — repositorio oficial (fuente original)
• Percona Announces Valkey-proxy, an Open Source Project to Ease Enterprise Migration to Valkey