Limbo – SQLite komplett neu in Rust geschrieben

• Limbo ist ein experimentelles Projekt zur Reimplementierung von SQLite in Rust, um Memory Safety zu bieten
  • Die eingebetteten Eigenschaften von SQLite gefielen dem Team, aber es wollte ein offeneres Entwicklungsmodell und startete daher das Projekt libSQL
• Warum SQLite geforkt wurde: Neue Funktionen lassen sich leichter integrieren, und die Kompatibilität mit bestehendem Code kann erhalten bleiben
  • Nachteil: Die Test-Suite von SQLite ist proprietär und in C geschrieben, was die Weiterentwicklung des Codes erschwert
• Neuer Ansatz
  • Beim Hinzufügen von Vector Search stieß man auf die Grenzen von SQLite
  • Durch ein komplettes Neuschreiben von SQLite von Grund auf wird ausgelotet, wie sich die Kompatibilität erhalten und zugleich neue Funktionen aggressiver hinzufügen lassen
• Nächste Schritte
  • Limbo wird zu einem offiziellen Turso-Projekt
  • Ziel ist der Aufbau einer neuen Architektur, die dieselbe Zuverlässigkeit wie SQLite beibehält und gleichzeitig Memory Safety bietet
• Die Zuverlässigkeit von SQLite herausfordern
  • Hohe Zuverlässigkeit wird durch deterministische Simulationstests (DST) erreicht
  • In Zusammenarbeit mit Antithesis wird ein DST-Framework auf Systemebene verwendet
• Aktueller Stand
  • Vollständig asynchrones I/O: Limbo setzt auf ein vollständig asynchrones Design und löst damit Probleme der synchronen Schnittstelle von SQLite
  • Für WASM entworfen: Das Design berücksichtigt den Einsatz in WASM-Umgebungen
  • Performance: Bei vielen Aufgaben erreicht Limbo eine mit SQLite vergleichbare oder schnellere Performance
  • Einfachheit: Durch das Entfernen von Funktionen, die in modernen Umgebungen weniger wichtig sind, wird eine bessere User Experience geboten
• Weitere Informationen
  • Limbo ist auf GitHub unter der MIT-Lizenz verfügbar
  • Eingeladen sind alle, die sich für den Bau eingebetteter Datenbanken interessieren und das Versprechen von SQLite auf die nächste Stufe heben möchten

[seonwoo960000]

Schon faszinierend, wenn ein Projekt, zu dem man beigetragen hat, auf Hacker News auftaucht, haha.

[GN⁺]

Hacker-News-Kommentare

• SQLite wirkt wie ein Projekt, das dank Codequalität und strenger Tests nicht neu geschrieben werden muss

  • Es gibt die Meinung, dass andere C-Codebasen zuerst neu geschrieben werden sollten

• Die Diskussion darüber, dass SQLite keine „offenen Beiträge“ habe, übersieht, dass Beiträge anzunehmen nicht immer bedeutet, sie auch zu akzeptieren

  • SQLite hat einen Prozess für Beiträge und setzt vorgeschlagene Funktionen auf diese Weise um
  • Andere Projekte im SQLite-Ökosystem wie Litestream und LiteFS haben ähnliche Beitragsrichtlinien

• Zur ersten Ankündigung des Forks von SQLite3 zu LibSQL gab es eine negative Haltung

  • Weil die Test-Suite von SQLite3 proprietär ist, wurde angenommen, dass der Fork mit hoher Wahrscheinlichkeit scheitern würde
  • Wenn es jedoch ein großes Produktziel wie eine Neuschreibung in einer speichersicheren Sprache gibt, ergibt ein Fork durchaus Sinn

• Für maximale Leistung sollte man den WAL-Modus wählen und POSIX-Advice-Locking deaktivieren

  • Es gibt die Frage, ob der Modus „wal2“ auf dem Radar des Projekts ist

• Es gibt die Meinung, dass dies das erste Mal sei, von der proprietären Natur der SQLite-Test-Suite zu hören

  • Android wurde auf ähnliche Weise aufgebaut, aber das ist ein anderes Thema

• Die Logik im Abschnitt „async IO“ überzeugt nicht

  • Es wird die Ansicht vertreten, dass SQLite nicht neu geschrieben werden muss, um eine asynchrone Schnittstelle hinzuzufügen
  • Das Problem der synchronen Schnittstelle von SQLite besteht darin, dass Threads beim Warten auf IO ungenutzt bleiben
  • SQLite ist dafür ausgelegt, sehr nah am Speicher ausgeführt zu werden, sodass IO-Blockierungen sehr kurz sein oder ganz entfallen können

• Es gibt die Meinung, dass sich das Projekt noch in einem frühen Stadium befindet

  • Es wird ein Codebeispiel mit Python und Limbo gezeigt

• Wenn man mit Fil-C kompiliert, erhält man ein speichersicheres SQLite

  • Es sind nur geringe Änderungen nötig, und fast die gesamte Test-Suite wird bestanden

• SQLite besteht aus etwa 156.000 Zeilen Code und 92.000 Zeilen Testcode

• Es wird vermutet, dass eine DO-178B-Zertifizierung für die Rust-Variante nicht in Betracht gezogen wird

• Der Name „Limbo“ wurde auch für eine Post-C/UNIX-Sprache des Inferno-Betriebssystems von AT&T verwendet

[aer0700]

SQLite wirkt wie ein Projekt, das dank Codequalität und strenger Tests gar nicht neu geschrieben werden muss -> um so eine Einschätzung zu SQLite kann man es wirklich beneiden, und sie ist großartig.

[regentag]

Es heißt, dass der DO-178B-Prozess eingehalten wird und eine MC/DC-Codeabdeckung von 100 % erreicht wurde.
Die unbekannte Geschichte von SQLite