KiviDB : une alternative à Redis en Rust avec recherche vectorielle intégrée

Un nouveau projet open source nommé KiviDB a fait son apparition comme une alternative haute performance à Redis et Valkey, écrite en Rust. Sorti en octobre 2026, il cible les ingénieurs d'infrastructure cherchant une compatibilité immédiate (drop-in) avec les clients Redis existants tout en ajoutant un support natif pour la recherche full-text et vectorielle. Le projet revendique des améliorations significatives du débit par rapport aux moteurs établis grâce à une architecture shardée et multi-cœur.

Ce qui s'est passé

KiviDB est conçu pour parler le protocole Redis, prenant en charge les standards RESP2 et RESP3. Cette compatibilité signifie que les outils existants comme redis-cli, ainsi que les bibliothèques clientes populaires, peuvent se connecter à KiviDB sans modification. Contrairement aux instances Redis traditionnelles qui reposent souvent sur une exécution mono-thread pour les commandes principales, KiviDB répartit la charge sur tous les cœurs CPU disponibles via une conception mémoire shardée. Il inclut également des mécanismes de persistance via des instantanés (snapshots) et un fichier journalisé optionnel (append-only file).

Le projet se distingue en intégrant directement les capacités de recherche dans le moteur principal. Les utilisateurs peuvent exécuter des commandes FT.* de style Redis Stack pour la recherche full-text, par balises, numérique et vectorielle sans installer de modules séparés. Lors de benchmarks effectués sur des instances bare metal AWS Graviton3, KiviDB a démontré des gains de performance substantiels. Sur une configuration à 32 cœurs, il a servi 21 millions d'opérations GET pipelinées par seconde, ce que les développeurs affirment être environ neuf fois plus rapide que Redis 8 et 2,3 fois plus rapide que Dragonfly.

Les métriques de latence ont également favorisé le nouveau moteur, avec une latence p99 signalée à moins de la moitié de celle de Dragonfly dans les scénarios pipelinés. Cependant, lors de tests non pipelinés, Dragonfly a conservé un léger avantage en opérations brutes par seconde. Ces résultats soulignent comment les modèles de charge, tels que le pipelining, influencent considérablement la performance relative de ces magasins en mémoire. Les benchmarks ont été réalisés dans un environnement contrôlé, et les auteurs recommandent de tester sur un matériel spécifique avant l'adoption en production.

Comment cela fonctionne

KiviDB atteint sa concurrence en exécutant les commandes sur chaque cœur via une architecture shardée. Cette approche contraste avec le modèle mono-thread de Redis standard ou le modèle shared-nothing de Dragonfly. En répartissant les clés entre les shards, le système permet le traitement parallèle des requêtes, réduisant la contention sur un seul thread. Le moteur est écrit en Rust, utilisant l'édition 2024 du langage, et repose sur une chaîne d'outils stable à partir de Rust 1.89.

Pour la recherche vectorielle, KiviDB implémente des algorithmes de voisins les plus proches approximatifs, supportant spécifiquement les index FLAT et HNSW. Les vecteurs sont stockés sous forme de bytes FLOAT32 little-endian bruts dans les champs hash, respectant la même convention utilisée par Redis Stack. Lorsqu'une requête de recherche est exécutée, le moteur utilise ces index pour trouver efficacement des vecteurs similaires. Le système persiste non seulement les données clé-valeur, mais aussi les schémas d'index et les graphes HNSW, garantissant que la qualité de la recherche reste cohérente après les redémarrages sans nécessiter de reconstruction complète.

Le logiciel offre de la flexibilité grâce aux fonctionnalités Cargo, permettant aux utilisateurs de compiler des variantes avec ou sans script Lua et support TLS. Par défaut, il fonctionne sans ces fonctionnalités pour minimiser les dépendances et la surface d'attaque. Sur les systèmes Linux, il tente d'utiliser io_uring pour les E/S asynchrones si le noyau le permet, retombant sur Tokio sinon. Cette gestion bas niveau des E/S contribue à sa capacité à gérer efficacement un grand nombre de connexions et un haut débit.

Détails clés

• Compatibilité Protocole : Prend en charge RESP2 et RESP3, permettant aux clients et outils Redis existants de se connecter sans modifications.
• Revendications de Performance : Les benchmarks montrent 21 millions de GETs pipelinés par seconde sur 32 cœurs, surpassant Redis 8 et Dragonfly dans des scénarios spécifiques.
• Recherche Intégrée : Inclut un support natif pour la recherche full-text, par balises, numérique et vectorielle utilisant les commandes FT.*, éliminant le besoin de modules externes.
• Architecture Multi-threadée : Utilise tous les cœurs CPU via une conception mémoire shardée, différant de la nature mono-thread de Redis standard.
• Options de Persistance : Prend en charge les instantanés (dump.kdb) et un fichier journalisé optionnel (AOF) pour la durabilité des données.
• Licence : Distribué sous la GNU Affero General Public License v3 (AGPL-3.0-only), ce qui peut avoir un impact sur l'utilisation dans les distributions logicielles propriétaires.

Pourquoi c'est important

Pour les ingénieurs logiciels développant des applications pilotées par l'IA, l'intégration de la recherche vectorielle directement dans la couche cache simplifie l'infrastructure. Traditionnellement, les équipes devaient gérer des services séparés pour le cache et la recherche de similarité vectorielle, entraînant une complexité opérationnelle accrue et des problèmes potentiels de cohérence. L'approche de KiviDB permet aux développeurs d'utiliser une interface unique pour les recherches clé-valeur rapides et la recherche sémantique, réduisant potentiellement le nombre de composants mobiles dans leur stack.

Les améliorations de performance rapportées dans les environnements multi-cœurs répondent à un goulot d'étranglement courant dans les systèmes à haut débit. À mesure que les applications passent à l'échelle, la limitation mono-thread de Redis traditionnel peut devenir une contrainte, forçant les équipes à sharding manuellement ou à adopter des solutions de clustering plus complexes. Le sharding automatique de KiviDB sur les cœurs offre une voie vers une meilleure utilisation des serveurs multi-cœurs modernes sans nécessiter de modifications au niveau de l'application pour gérer la logique de sharding.

Cependant, le choix de la licence est une considération critique pour les responsables techniques. La licence AGPL-3.0 exige que si vous modifiez le logiciel et le fournissez via un réseau, vous devez rendre le code source disponible. Bien que l'utilisation de KiviDB comme service ne force pas nécessairement votre code applicatif à être open source, une revue juridique est essentielle pour les organisations ayant des exigences propriétaires strictes. Cela contraste avec des alternatives comme Valkey, qui utilise une licence BSD-3-Clause, offrant des termes plus permissifs pour un usage commercial.

Ce que vous pouvez faire

• Testez KiviDB localement en utilisant Docker en lançant docker run -d -p 6380:6380 kividb/kividb et connectez-vous avec redis-cli -p 6380.
• Benchmark votre charge de travail spécifique contre KiviDB, Redis et Dragonfly pour déterminer si l'architecture multi-threadée apporte des avantages tangibles pour votre cas d'usage.
• Examinez les implications de la licence AGPL-3.0 avec votre équipe juridique si vous prévoyez d'utiliser KiviDB dans un produit commercial ou un service distribué.
• Expérimentez avec les capacités de recherche vectorielle intégrées en créant des index avec FT.CREATE et en les interrogeant avec FT.SEARCH pour évaluer la qualité de la recherche et la latence.
• Configurez la persistance en activant le drapeau du fichier journalisé (--aof) dans Docker ou les arguments de ligne de commande pour assurer la durabilité des données lors des redémarrages.
• Surveillez l'utilisation mémoire, car la mémoire par clé de KiviDB a été signalée à 177 octets dans les benchmarks, légèrement supérieure aux 134 octets de Dragonfly mais comparable à Redis.