TurboKV: Async Key-Value-Store in Rust
- TurboKV 0.6 ist eine asynchrone eingebettete Key-Value-Datenbank in Rust mit atomaren Batches, drei Dauerhaftigkeitsstufen und Hardware-AES-Bloom-Filtern.
- Im Benchmark auf Apple M4 erreicht TurboKV im sequentiellen Batch-Modus bis zu 2,33 Mio. ops/s – 4,075× mehr als fjall unter denselben Bedingungen.
- Der redb-Vergleich bei Einzeltransaktionen ist laut Benchmark-Dokumentation nicht 1:1 übertragbar, da redb auf macOS pro Transaktion ein F_BARRIERFSYNC durchführt.
TurboKV, eine in Rust geschriebene asynchrone eingebettete Key-Value-Datenbank, ist in Version 0.6 verfügbar. Die Bibliothek unterstützt atomare Batches, geordnete Bereichsabfragen, konfigurierbare Dauerhaftigkeitsstufen, Komprimierung und Hintergrund-Compaction – und positioniert sich mit Benchmark-Ergebnissen als schnelle Alternative zu bestehenden eingebetteten Rust-Datenbanken.
Drei Dauerhaftigkeitsstufen
TurboKV bietet drei vordefinierte Konfigurationsprofile: DbOptions::fast() verzichtet vollständig auf ein Write-Ahead-Log (WAL) und eignet sich für flüchtige Caches. DbOptions::durable() schreibt Mutationen in das WAL, ohne vor der Bestätigung zu synchronisieren – dieser Modus schützt vor Prozessabstürzen und gilt als empfohlener Standard. DbOptions::paranoid() führt vor jeder Bestätigung ein vollständiges WAL-Sync durch und bietet damit die stärkste Garantie, abhängig von Dateisystem und Hardware. Alle Presets starten standardmäßig mit einem 64-MiB-Memtable, einem 64-MiB-Block-Cache und LZ4-Komprimierung. Unterstützte Komprimierungsvarianten sind Lz4, Snappy, Zstd sowie keine Komprimierung. Der persistierte Bloom-Filter nutzt Hardware-AES; für x86/x86_64-Targets sind die entsprechenden Compiler-Flags erforderlich.
API: Von Einzeloperationen bis zu Batch-Schreibvorgängen
Die Datenbank akzeptiert Schlüssel und Werte als beliebige Byte-Sequenzen. Einzeloperationen wie insert, get, remove und contains_key arbeiten asynchron. Atomare Batch-Schreibvorgänge über WriteBatch garantieren, dass Leser entweder den Zustand vor oder nach dem gesamten Batch sehen. Bereichs- und Präfixabfragen liefern lexikografisch geordnete Ergebnisse; streaming-Iteratoren pinnen einen konsistenten Snapshot und sollten nach Nutzung umgehend freigegeben werden, da sie Datenbankverzeichnis-Ownership halten. insert_many ist ausdrücklich kein atomarer Sichtbarkeitsübergang, sondern eine Bulk-API. Mit WAL aktiviert muss ein einzelner Datensatz oder ein vollständiger Batch in die u32-Nutzlastlänge des WAL passen. Die Bibliothek ist auch für verwandte Projekte wie systemnahe Rust-Entwicklung mit KI-Unterstützung relevant, wo typsichere, performante Datenpersistenz eine zentrale Rolle spielt.
Benchmark: TurboKV gegen fjall und redb
Die veröffentlichten Benchmarks wurden am 28. August 2026 auf einem Apple M4 (Mac16,1) mit 32 GiB RAM, macOS 15.3.2, APFS und rustc 1.88.0 gemessen. Verglichen wurden TurboKV 0.6.0, fjall 2.11.2 und redb 2.6.3, jeweils im Durable-Modus. Der Test umfasste 200.000 deterministische 20-Byte-Schlüssel mit 400-Byte-Werten (84 MB logischer Input), ohne Komprimierung und ohne Block-Cache-Bereinigung, mit einem einzigen aufrufenden Thread.
| Workload | TurboKV ops/s | fjall ops/s | redb ops/s | TurboKV / fjall |
|---|---|---|---|---|
| Sequentielles Füllen (1 Key/Txn) | 1.407.678 | 485.252 | 1.397 | 2,901× |
| Zufälliges Füllen (1 Key/Txn) | 834.137 | 456.924 | 1.549 | 1,826× |
| Überschreiben (1 Key/Txn) | 853.083 | 446.733 | 1.516 | 1,910× |
| Sequentieller Batch (100 Keys/Txn) | 2.272.259 | 511.600 | 80.197 | 4,441× |
| Sequentieller Batch (1.000 Keys/Txn) | 2.333.582 | 572.671 | 134.636 | 4,075× |
Die auffällig niedrigen redb-Werte bei Einzelschlüssel-Transaktionen erklären sich durch ein architektonisches Merkmal: redb 2.6.3 führt auf macOS für jede Transaktion ein F_BARRIERFSYNC durch, was einer anderen Dauerhaftigkeitssemantik entspricht als der prozessabsturzsichere OS-Cache-Grenzwert von TurboKV und fjall. Die Benchmark-Autoren weisen ausdrücklich darauf hin, dass die Einzelschlüssel-Ergebnisse von redb daher als architektonischen Kontext zu verstehen sind, nicht als gleichwertige Durability-Vergleichszahl. Ein direkter Vergleich abgesicherter Timings über alle drei Engines hinweg wird nicht angestellt. Im Batch-Betrieb, wo der feste Barrier-Overhead amortisiert wird, nähert sich redb deutlicher an die anderen Engines an. Für Entwickler, die eingebettete Datenbankoptionen im Rust-Ökosystem evaluieren, bietet auch das Projekt BriskDB als SQLite-basierte Sharding-Datenbank einen interessanten Vergleichspunkt.
Einordnung
TurboKV richtet sich an Anwendungen, die eine eingebettete, asynchrone Datenpersistenz mit fein abstimmbaren Garantien benötigen. Die veröffentlichten Messwerte stammen aus einem Einzelthread-Szenario auf einer spezifischen Apple-M4-Hardware; ob die Leistungsvorteile unter anderen Bedingungen – insbesondere bei nebenläufigen Workloads oder auf x86-Servern – in gleichem Maße reproduzierbar sind, lässt sich aus dem vorliegenden Material nicht ableiten.
Themen
Organisationen
