SQLite ist die am weitesten verbreitete Datenbank der Welt — und fast niemand spricht darüber

Die Datenbanken, die Aufmerksamkeit bekommen, sind die, die Sie betreiben: PostgreSQL-Cluster, MySQL-Replikate, MongoDB-Shards, Cloud-verwaltete Dienste von AWS und Google. Die Datenbank, die an mehr Orten ist als alle zusammen, läuft leise im Hintergrund, benötigt keinen Administrator, verbraucht weniger als 1 MB Festplattenspeicher für ihre Bibliothek und ist eine einzige C-Quelldatei, die jeder Entwickler an einem Nachmittag lesen kann.

SQLite ist überall. Es ist die Speicher-Engine in jeder iOS- und Android-Anwendung, die strukturierte Daten benötigt. Es ist in jedem Desktop-Browser eingebettet – Chrome, Firefox, Safari und Edge verwenden alle SQLite für Verlauf, Lesezeichen und zwischengespeicherte Daten. Es ist die Datenbank, die die Flugverwaltungssoftware in Airbus- und Boeing-Flugzeugen antreibt. Es ist in Fernsehern, Autos, Routern und medizinischen Geräten. Das SQLite-Projekt schätzt über eine Billion aktive Installationen – eine so große Zahl, dass es schwer zu überprüfen, aber angesichts der vielen darauf aufbauenden Software-Stapel auch schwer zu bestreiten ist.

Das Design, das es anders macht

Jede andere SQL-Datenbank, die Sie wahrscheinlich verwendet haben, ist ein Client-Server-System: Die Datenbank läuft als separater Prozess, Sie verbinden sich über einen Socket (lokal oder Netzwerk), senden Abfragen und erhalten Ergebnisse. SQLite ist serverlos – die gesamte Datenbank-Engine ist eine Bibliothek, die innerhalb Ihres Anwendungsprozesses läuft. Es gibt keinen zu startenden Server, keine zu verwaltende Konfigurationsdatei, kein Benutzerberechtigungssystem, keinen zu öffnenden Netzwerkport. Sie linken die Bibliothek und haben eine vollständige SQL-Datenbank.

Die Datenbank selbst ist eine einzelne Datei im Dateisystem. Dies ist sowohl ihre größte Stärke als auch ihre entscheidende Einschränkung. Das Verschieben einer SQLite-Datenbank ist ein Dateikopieren. Das Sichern ist ein Dateikopieren. Das Untersuchen erfordert keine speziellen Werkzeuge – SQLite Browser oder die sqlite3 CLI öffnen jede Datenbankdatei auf jedem Betriebssystem. Wenn Ihre Anwendung beendet ist, gibt es nichts herunterzufahren.

Die Einschränkung ist die Parallelität: SQLite verwendet Dateisperren, was bedeutet, dass nur ein Schreiber die Datenbank gleichzeitig ändern kann. Mehrere gleichzeitige Leser sind in Ordnung; mehrere gleichzeitige Schreiber werden serialisiert. Für Anwendungen mit hoher Schreibparallelität – stark frequentierte Webserver, die gleichzeitige Anfragen bearbeiten – ist diese Einschränkung wichtig. Für die überwältigende Mehrheit der Anwendungen, einschließlich der meisten mobilen Apps, Desktop-Tools und mäßig frequentierte Webdienste, tut sie das nicht.

Warum SQLite zuverlässig genug zum Fliegen ist

Die Codebasis von SQLite ist eine der gründlichst getesteten Software überhaupt. Das Projekt unterhält etwa 600-mal mehr Testcode als Produktionscode – die Bibliothek selbst umfasst etwa 150.000 Zeilen C; die Testsuite umfasst etwa 90 Millionen Zeilen, einschließlich eines vollständigen SQL-Fuzzers, TH3 (ein kommerzielles Test-Framework für rigorose Tests gegen Randfälle) und umfassende Korruptionswiederherstellungstests.

Der Zuverlässigkeitsstandard ist für Open-Source-Software ungewöhnlich. D. Richard Hipp, der Schöpfer von SQLite, hat es explizit für sicherheitskritische Luftfahrtsysteme ausgelegt, und Airbus und andere haben es entsprechend zertifiziert. Die Datenbank bietet ACID-Garantien – Atomarität, Konsistenz, Isolation, Dauerhaftigkeit – durch ein Write-Ahead-Log-System. Ein Absturz mitten in einer Transaktion hinterlässt die Datenbank in einem bekannten guten Zustand; das WAL stellt sicher, dass entweder die gesamte Transaktion festgeschrieben wird oder keine davon, selbst bei unerwartetem Stromausfall.

Die überraschende Leistungsuntergrenze

SQLites serverlose Architektur bedeutet, dass es den Overhead vermeidet, den Client-Server-Datenbanken verursachen: keine Serialisierung von Daten zur Übertragung über einen Socket, kein Kontextwechsel zwischen Client- und Server-Prozessen, keine Abfrageplanung über eine Netzwerkgrenze hinweg. Für Workloads mit einfachen Abfragen und kleinen bis mittelgroßen Datenbanken ist die Leistung von SQLite oft vergleichbar mit PostgreSQL und manchmal schneller.

Das SQLite-Team führte 2022 Benchmarks durch, die zeigten, dass SQLite bei einem leseintensiven Workload (35 Lesevorgänge pro Schreibvorgang) auf einer handelsüblichen NVMe-SSD 48.000 Transaktionen pro Sekunde verarbeitete, verglichen mit 7.000 bei PostgreSQL – hauptsächlich, weil die prozessinterne Architektur von SQLite den Overhead der Interprozesskommunikation eliminiert. Bei schreibintensiven Workloads ist das Bild differenzierter; die gleichzeitige Schreibverarbeitung von PostgreSQL verschafft ihm Vorteile in Szenarien mit hohem Wettbewerb.

Die praktische Implikation: Viele Anwendungen, die standardmäßig PostgreSQL verwenden, weil es als "produktionstauglich" gilt, würden mit SQLite gut funktionieren und betrieblich einfacher sein. Cloudflares D1 verteilter SQLite-Dienst und Turso's libSQL (ein Fork von SQLite mit Replikationsunterstützung) bauen Infrastruktur um die Wette, dass die Einfachheit von SQLite in serverseitigen Anwendungen unterbewertet wurde.

Modernes SQLite: Nicht die Version von 2005

SQLite hat sich erheblich weiterentwickelt. Die JSON-Unterstützung, die 2015 hinzugefügt und bis 2022 erweitert wurde, ermöglicht das Abfragen und Indizieren von verschachtelten JSON-Daten mit vollständiger SQL-Semantik – konkurrenzfähig mit Dokumentdatenbanken für viele Anwendungsfälle. Die Full-Text Search 5 (FTS5)-Erweiterung bietet BM25-bewertete Volltextsuche mit Präfixabfragen, ohne dass ein separater Suchindex erforderlich ist. Die R*Tree-Erweiterung behandelt georäumliche Bereichsabfragen. Virtuelle Tabellen ermöglichen es SQLite, externe Datenquellen (CSV-Dateien, Remote-APIs) mit SQL-Syntax abzufragen.

Die neueste Ergänzung ist die Vektorähnlichkeitssuche-Erweiterung – sqlite-vss, basierend auf Facebooks FAISS-Bibliothek – die eine approximative Nächste-Nachbarn-Suche zu SQLite hinzufügt. Das bedeutet, dass eine einzelne SQLite-Datei Dokumente, deren Vektor-Embeddings speichern und semantische Ähnlichkeitssuche durchführen kann, was sie zu einer brauchbaren eingebetteten RAG-Datenbank (Retrieval-Augmented Generation) für lokale KI-Anwendungen macht. Die Kombination aus strukturierten Abfragen, Volltextsuche und Vektorsuche in einer einzigen, konfigurationslosen Datenbank ist überzeugend für Anwendungen, die zuvor drei separate Systeme erforderten.

Wann man SQLite nicht verwenden sollte

Die ehrliche Antwort auf "Sollte ich SQLite verwenden?" erfordert die Anerkennung seiner tatsächlichen Einschränkungen. Hochparallele Schreib-Workloads – denken Sie an eine Webanwendung, die Tausende gleichzeitiger Transaktionen verarbeitet – benötigen die Mehrfachschreiber-Parallelität, die PostgreSQL bietet. Datensätze, die wesentlich größer als der verfügbare RAM sind, profitieren von PostgreSQLs Pufferpool-Verwaltung und Abfrageplaner, der für große Datenszenarien optimiert ist. Anwendungen, die eine feinkörnige Zugriffskontrolle (zeilenbasierte Sicherheit, spaltenbasierte Berechtigungen) erfordern, benötigen eine serverbasierte Datenbank.

Aber dies sind Einschränkungen, die eine Minderheit der Installationen betreffen. Die typische CRUD-Webanwendung, die mobile App, das Desktop-Tool, das eingebettete System und das Datenpipeline-Skript werden alle gut von SQLites Einfachheit bedient. Der Rat, dass SQLite "nicht skalierbar" oder "nicht produktionsreif" sei, ist seit einem Jahrzehnt veraltet – es skaliert vertikal auf sehr große Größen und betreibt seit den frühen 2000ern zuverlässig Produktionsanwendungen. Die Kluft zwischen SQLites tatsächlichen Fähigkeiten und seinem Ruf bei Entwicklern, die es in letzter Zeit nicht verwendet haben, ist erheblich und eine Korrektur wert.