KiviDB: Eine Rust-basierte Redis-Alternative mit integrierter Vektorsuche

Das neue Open-Source-Projekt KiviDB hat sich als leistungsstarke Alternative zu Redis und Valkey etabliert. Es wurde in Rust geschrieben und im Oktober 2026 veröffentlicht. Das Projekt richtet sich an Infrastruktur-Ingenieure, die eine Drop-in-Kompatibilität zu bestehenden Redis-Clients suchen, jedoch native Unterstützung für Volltext- und Vektorsuche benötigen. Die Entwickler behaupten, dass KiviDB durch die Nutzung einer shard-basierten, Multi-Core-Architektur erhebliche Durchsatzverbesserungen gegenüber etablierten Engines erzielt.

Was passiert ist

KiviDB ist so konzipiert, dass es das Redis-Protokoll spricht und sowohl die Standards RESP2 als auch RESP3 unterstützt. Diese Kompatibilität bedeutet, dass bestehende Tools wie redis-cli sowie gängige Client-Bibliotheken ohne Modifikationen eine Verbindung zu KiviDB herstellen können. Im Gegensatz zu traditionellen Redis-Instanzen, die bei Kernbefehlen oft auf Single-Threaded-Ausführung setzen, verteilt KiviDB die Arbeit über alle verfügbaren CPU-Kerne hinweg unter Verwendung eines shard-basierten In-Memory-Designs. Es umfasst zudem Persistenzmechanismen über Snapshots und eine optionale Append-Only-File (AOF).

Das Projekt hebt sich dadurch ab, dass Suchfunktionen direkt in die Core-Engine integriert sind. Benutzer können FT.*-Befehle im Stil von Redis Stack für Volltext-, Tag-, numerische und Vektorsuchen ausführen, ohne separate Module installieren zu müssen. In Benchmarks auf AWS Graviton3 Bare-Metal-Instanzen zeigte KiviDB erhebliche Leistungssteigerungen. Bei einer 32-Core-Konfiguration verarbeitete es 21 Millionen pipelined GET-Operationen pro Sekunde. Laut den Entwicklern ist dies etwa neunmal schneller als Redis 8 und 2,3-mal schneller als Dragonfly.

Auch die Latenzmetriken sprachen für die neue Engine: Die p99-Latenz lag in Pipelining-Szenarien bei weniger als der Hälfte der von Dragonfly gemessenen Werte. Allerdings behielt Dragonfly in Nicht-Pipelining-Tests einen leichten Vorsprung bei den reinen Operationen pro Sekunde. Diese Ergebnisse verdeutlichen, wie stark Arbeitslastmuster wie Pipelining die relative Leistung dieser In-Memory-Speicher beeinflussen. Die Benchmarks wurden in einer kontrollierten Umgebung durchgeführt; die Autoren empfehlen daher, Tests auf spezifischer Hardware vorzunehmen, bevor man KiviDB produktiv einsetzt.

Wie es funktioniert

KiviDB erreicht seine Nebenläufigkeit, indem Befehle über alle Kerne hinweg in einer shard-basierten Architektur ausgeführt werden. Dieser Ansatz steht im Kontrast zum Single-Threaded-Modell des Standard-Redis oder dem Shared-Nothing-Modell von Dragonfly. Durch die Verteilung der Schlüssel über Shards ermöglicht das System die parallele Verarbeitung von Anfragen und reduziert Kontention auf einzelnen Threads. Die Engine ist in Rust geschrieben, nutzt die Edition 2024 der Sprache und basiert auf einem stabilen Toolchain ab Rust 1.89.

Für die Vektorsuche implementiert KiviDB Approximate Nearest Neighbor-Algorithmen und unterstützt speziell FLAT- und HNSW-Indizes. Vektoren werden als rohe FLOAT32 Little-Endian-Bytes innerhalb von Hash-Feldern gespeichert, wobei dieselbe Konvention wie bei Redis Stack eingehalten wird. Wenn eine Suchabfrage ausgeführt wird, nutzt die Engine diese Indizes, um ähnliche Vektoren effizient zu finden. Das System persistiert nicht nur die Key-Value-Daten, sondern auch die Index-Schemas und HNSW-Graphen. Dies stellt sicher, dass die Suchqualität nach Neustarts konsistent bleibt, ohne dass ein vollständiger Rebuild erforderlich ist.

Die Software bietet Flexibilität durch Cargo-Features, die es Benutzern erlauben, Varianten mit oder ohne Lua-Scripting und TLS-Unterstützung zu erstellen. Standardmäßig läuft sie ohne diese Funktionen, um Abhängigkeiten und Angriffsfläche zu minimieren. Auf Linux-Systemen versucht KiviDB, io_uring für asynchrone I/O-Operationen zu nutzen, sofern der Kernel dies erlaubt, und fällt sonst auf Tokio zurück. Diese Low-Level-I/O-Verarbeitung trägt zur Fähigkeit bei, hohe Verbindungsanzahlen und Durchsätze effizient zu verwalten.

Wichtige Details

• Protokollkompatibilität: Unterstützt RESP2 und RESP3, sodass bestehende Redis-Clients und Tools ohne Änderungen verbinden können.
• Leistungsangaben: Benchmarks zeigen 21 Millionen pipelined GETs pro Sekunde auf 32 Kernen, was Redis 8 und Dragonfly in bestimmten Szenarien übertrifft.
• Integrierte Suche: Enthält native Unterstützung für Volltext-, Tag-, numerische und Vektorsuche mittels FT.*-Befehlen, wodurch externe Module entfallen.
• Multi-threaded Architektur: Nutzt alle CPU-Kerne über ein shard-basiertes In-Memory-Design, im Gegensatz zur Single-Threaded-Natur von Standard-Redis.
• Persistenzoptionen: Unterstützt Snapshots (dump.kdb) und eine optionale Append-Only-File (AOF) für Datenhaltbarkeit.
• Lizenzierung: Veröffentlicht unter der GNU Affero General Public License v3 (AGPL-3.0-only), was Auswirkungen auf die Nutzung in proprietärer Software haben kann.

Warum es wichtig ist

Für Software-Ingenieure, die KI-gestützte Anwendungen entwickeln, vereinfacht die Integration der Vektorsuche direkt in die Cache-Ebene die Infrastruktur. Traditionell mussten Teams separate Dienste für Caching und Vektorähnlichkeitssuche verwalten, was zu erhöhter operativer Komplexität und potenziellen Konsistenzproblemen führte. Der Ansatz von KiviDB ermöglicht es Entwicklern, eine einzige Schnittstelle für schnelle Key-Value-Lookups und semantische Suche zu nutzen, was die Anzahl der beweglichen Teile im Stack reduzieren kann.

Die in Multi-Core-Umgebungen berichteten Leistungsverbesserungen adressieren einen häufigen Engpass in Hochdurchsatzsystemen. Wenn Anwendungen skalieren, kann die Single-Threaded-Beschränkung des traditionellen Redis zum Hindernis werden, was Teams zwingt, manuell zu sharden oder komplexere Clustering-Lösungen einzuführen. KiviDBs automatisches Sharding über Kerne hinweg bietet einen Weg zu höherer Auslastung moderner Multi-Core-Server, ohne dass applikationsseitige Änderungen zur Handhabung der Shard-Logik erforderlich sind.

Allerdings ist die Wahl der Lizenz eine kritische Überlegung für technische Leads. Die AGPL-3.0-Lizenz verlangt, dass Sie, wenn Sie die Software modifizieren und über ein Netzwerk bereitstellen, den Quellcode verfügbar machen müssen. Während die Nutzung von KiviDB als Dienst Ihren Anwendungscode nicht unbedingt dazu zwingt, Open Source zu sein, ist eine rechtliche Prüfung für Organisationen mit strengen proprietären Anforderungen essenziell. Dies steht im Kontrast zu Alternativen wie Valkey, die eine BSD-3-Clause-Lizenz verwendet und permissivere Bedingungen für kommerzielle Nutzung bietet.

Was Sie tun können

• Testen Sie KiviDB lokal mit Docker, indem Sie docker run -d -p 6380:6380 kividb/kividb ausführen und sich mit redis-cli -p 6380 verbinden.
• Führen Sie Benchmarks Ihrer spezifischen Workloads gegen KiviDB, Redis und Dragonfly durch, um festzustellen, ob die Multi-Threaded-Architektur greifbare Vorteile für Ihren Use Case bietet.
• Prüfen Sie die Implikationen der AGPL-3.0-Lizenz mit Ihrem Rechtsteam, wenn Sie planen, KiviDB in einem kommerziellen Produkt oder verteilten Dienst einzusetzen.
• Experimentieren Sie mit den integrierten Vektorsuchfunktionen, indem Sie Indizes mit FT.CREATE erstellen und diese mit FT.SEARCH abfragen, um Suchqualität und Latenz zu bewerten.
• Konfigurieren Sie die Persistenz, indem Sie das Flag für die Append-Only-File (--aof) in Docker oder über Kommandozeilenargumente aktivieren, um Datenhaltbarkeit über Neustarts hinweg sicherzustellen.
• Überwachen Sie die Speichernutzung, da KiviDBs Speicherbedarf pro Schlüssel in Benchmarks mit 177 Bytes angegeben wurde – etwas höher als Dragonflys 134 Bytes, aber vergleichbar mit Redis.