Die Entwicklung von verteiltem SQLite: Von rqlite zu verwalteten Cloud-Diensten

Im September 2014 veröffentlichte Philip O'Toole rqlite, ein Open-Source-System, das SQLite mit dem Raft-Konsensprotokoll kombinierte, um eine fehlertolerante Cluster-Datenbank zu schaffen. Zwölf Jahre später reflektiert O'Toole darüber, wie dieses anfängliche Experiment eine breitere Kategorie verteilter SQLite-Lösungen auslöste, die von lokalen CRDTs bis hin zu VC-finanzierten Managed Services reicht.

Was geschah

O'Toole entwickelte rqlite ursprünglich, um ein spezifisches Infrastrukturproblem bei jut.io zu lösen: die Bereitstellung relationaler Speicherung für ein Clustersystem, ohne einen einzelnen Knoten als permanenten Datenträger festzulegen. Durch die Platzierung eines Raft-Logs vor SQLite stellte er sicher, dass jeder Schreibvorgang über den Cluster repliziert wurde, was Datenverlust bei einem Knotenausfall verhinderte. Der Quellcode wurde noch am selben Wochenende auf GitHub veröffentlicht, was laut O'Toole die erste Open-Source-Kombination aus Raft und SQLite markierte. Mehrere Jahre lang stand rqlite allein in dieser Nische, da keine anderen großen Projekte eine ähnliche Architektur versuchten.

Das Landschaftsbild begann sich 2016 zu verändern, als Expensify Bedrock veröffentlichte, ein Paxos-basiertes SQLite-Replikationssystem, das sie intern jahrelang genutzt hatten. Etwa zur gleichen Zeit erschien ActorDB, das Raft-replizierte SQLite-Datenbanken für einzelne Akteure in einer Erlang-Umgebung bot. Obwohl weder Bedrock noch ActorDB außerhalb ihrer Ursprungsunternehmen breite Adoption fanden, zeigten sie, dass das Konzept der SQLite-Replikation an Zuspruch gewann. Rqlite blieb jedoch als eigenständiges, universell einsetzbares Tool einzigartig, das jeder Entwickler unabhängig von einem bestimmten Anwendungsframework bereitstellen konnte.

Bis 2017 entwickelte Canonical dqlite, um einen eingebetteten replizierten Speicher für LXD und MicroK8s bereitzustellen und so den operativen Overhead des Betriebs von etcd zu vermeiden. Obwohl O'Toole und Mark Shuttleworth mögliche Kooperationen diskutierten, divergierten die Projekte in ihren Packaging-Modellen. Dqlite wurde zu einer C-Bibliothek, die direkt in Anwendungen eingebettet wird, während rqlite ein separater Serverprozess blieb. Diese Unterscheidung definierte ihre jeweiligen Anwendungsfälle: dqlite für Datenbankfunktionen innerhalb von Produkten und rqlite für Datenbankinfrastruktur neben ihnen.

Wie es funktioniert

Der Kernmechanismus von rqlite basiert auf dem Raft-Konsensalgorithmus zur Verwaltung des Zustands über mehrere Knoten hinweg. In diesem CP-System (Consistency and Partition tolerance) müssen alle Schreiboperationen an den Leader-Knoten gerichtet werden. Der Leader fügt die Änderung seinem Log hinzu und repliziert sie an die Follower-Knoten. Ein Schreibvorgang gilt erst dann als erfolgreich, wenn die Mehrheit des Clusters ihn bestätigt hat. Wenn eine Netzwerkpartition eine Minderheit der Knoten isoliert, verweigern diese Knoten Schreibvorgänge, um Datenabweichungen zu verhindern, was starke Konsistenz auf Kosten der Verfügbarkeit während Partitionen gewährleistet.

Dieses Design steht im starken Kontrast zu späteren Ansätzen wie Litestream, das 2021 von Ben Johnson veröffentlicht wurde. Litestream verwendet keine Konsensprotokolle. Stattdessen überwacht es das SQLite Write-Ahead Log (WAL) und streamt Änderungen in Objektspeicher wie S3. Dies bietet Disaster Recovery für Single-Node-Bereitstellungen zu minimalen Kosten und adressiert das häufige Bedürfnis nach Backup statt Echtzeit-Clustering. Rqlite beantwortet die Frage der Hochverfügbarkeit, wo Ausfallzeiten inakzeptabel sind, während Litestream die Datendauerhaftigkeit für einfachere Architekturen sicherstellt.

Neuere Innovationen haben verschiedene Punkte im Designraum erkundet. Cr-sqlite führt Conflict-free Replicated Data Types (CRDTs) als SQLite-Erweiterung ein, die mehreren Schreibern erlaubt, Änderungen ohne zentralen Leader zu divergieren und zusammenzuführen. Dieser AP-Ansatz (Availability and Partition tolerance) eignet sich für lokale-first-Anwendungen, bei denen sofortige Konsistenz weniger kritisch ist als Offline-Fähigkeit. Gleichzeitig haben Projekte wie libSQL die SQLite-Engine selbst geforkt, um tiefere Integrationen zu ermöglichen, die Dienste wie Turso betreiben, welche edge-replizierte Datenbanken als Managed Product anbieten.

Wichtige Details

• Rqlite wurde im September 2014 veröffentlicht und nutzte zunächst die goraft-Bibliothek, bevor es Anfang 2016 auf die Hashicorp-Raft-Implementierung wechselte.
• Canonicals dqlite, erstellt 2017, ist eine in Anwendungen eingebettete C-Bibliothek, während rqlite als eigenständiger Server operiert.
• Litestream, gestartet 2021, streamt SQLite-WAL-Dateien zu S3 für Disaster Recovery ohne Verwendung von Konsensprotokollen.
• Cr-sqlite ermöglicht Multi-Writer-Support durch CRDTs und bedient lokale-first-Anwendungen, die eventual consistency erfordern.
• Turso, aufgebaut auf dem libSQL-Fork, wurde 2026 von Supabase übernommen, was die kommerzielle Tragfähigkeit verwalteter verteilter SQLite-Lösungen unterstreicht.
• Cloudflares D1 und Durable Objects repräsentieren den Wandel hin zu serverlosen, verwalteten SQLite-Replikationen am Edge.

Warum es wichtig ist

Für Software-Ingenieure und Infrastructure-Leads klärt das Verständnis der Geschichte von verteiltem SQLite die Trade-offs zwischen verschiedenen Architekturmustern. Das Aufkommen dreier unterschiedlicher Ecken im Designraum – konsensbasiertes Clustering, WAL-Streaming und CRDT-Merging – bedeutet, dass die Wahl einer Lösung eine präzise Definition der Anforderungen erfordert. Entwickler müssen entscheiden, ob sie starke Konsistenz mit Hochverfügbarkeit, kosteneffektives Disaster Recovery oder offline-first Kollaborationsfähigkeiten benötigen. Die falsche Anwendung eines CP-Systems wie rqlite auf einen Use Case, der nur Backup benötigt, oder umgekehrt kann zu unnötiger Komplexität oder Datenrisiken führen.

Die Entwicklung von Open-Source-Tools zu Managed Platforms spiegelt auch einen breiteren Trend in der Infrastruktursoftware wider. Während rqlite, dqlite und Litestream weiterhin frei und Open Source bleiben, flossen erhebliches Venture Capital und Übernahmen zu Diensten, die operative Komplexität abstrahieren. Unternehmen wie Turso und Cloudflare verkaufen replizierte SQLite als Utility, sodass Teams den Wartungsaufwand für das Management von Clustern umgehen können. Dieser Wandel validiert die zugrunde liegende Technologie, verändert aber das Wirtschaftsmodell für Entwickler, die zuvor auf Self-Hosted-Lösungen vertrauten.

Was Sie tun können

• Bewerten Sie Ihre Konsistenzanforderungen: Wählen Sie Raft-basierte Systeme wie rqlite für starke Konsistenz oder CRDTs wie cr-sqlite für offline-first Apps.
• Erwägen Sie Litestream, wenn Ihr primäres Bedürfnis Disaster Recovery für eine Single-Node-SQLite-Datenbank ist, nicht Echtzeit-Clustering.
• Verwenden Sie dqlite, wenn Sie eine Anwendung entwickeln, die eine eingebettete, replizierte Datenbank ohne externe Serviceabhängigkeiten erfordert.
• Erkunden Sie Managed Services wie Turso oder Cloudflare D1, wenn Sie den operativen Overhead für das Management verteilter Datenbankcluster auslagern möchten.
• Prüfen Sie die WAL-Streaming-Funktionen in rqlite v8.0, die von Litestream inspiriert wurden, um Backup- und Wiederherstellungsprozesse zu optimieren.
• Beurteilen Sie, ob Ihr Team über die Expertise verfügt, einen Self-Hosted-Raft-Cluster zu warten, oder ob eine Managed Platform eine bessere Ressourcenzuteilung bietet.