SQLite ist keine Spielzeug-Datenbank – und immer mehr Produktionsanwendungen beweisen das

SQLite ist die am weitesten verbreitete Datenbank-Engine überhaupt. Sie läuft auf jedem Android-Gerät, jedem iPhone, jedem Desktop-Browser, jedem Mac und den meisten Windows-Systemen. Schätzungen zufolge sind über eine Billion SQLite-Datenbanken aktiv im Einsatz. Und während des größten Teils seiner Geschichte galt die implizite Regel in der Webentwicklung: SQLite ist in Ordnung für Entwicklung und Tests, aber vor dem Deployment steigt man auf Postgres oder MySQL um.

Diese Regel wird aktiv infrage gestellt – nicht als konträrer Standpunkt, sondern von Entwicklern, die echte Produktionssysteme betreiben und über echte Ergebnisse berichten. Der Wandel ist teils philosophisch, teils technisch.

Der traditionelle Einwand

Das Standardargument gegen SQLite in Produktions-Webanwendungen stützt sich auf Parallelität. SQLite ist eine dateibasierte Datenbank: Alle Lese- und Schreiboperationen erfolgen auf einer einzigen Datei auf der Festplatte. Während mehrere gleichzeitige Leser unterstützt werden, ist immer nur ein Schreiber gleichzeitig erlaubt. Im WAL-Modus (Write-Ahead Logging), der seit 2010 verfügbar ist, blockieren sich Leser und der einzelne Schreiber nicht gegenseitig – aber es gibt weiterhin nur einen Schreiber. Für Anwendungen mit hoher Schreibparallelität ist dies eine harte Einschränkung.

Der zweite Einwand ist betrieblicher Natur: Wenn Ihre Anwendung auf mehreren Servern läuft, können diese keine SQLite-Datei gemeinsam nutzen. Verteilte Datenbanken wie Postgres über TCP/IP sind dafür ausgelegt; SQLite nicht. Dies machte SQLite für horizontal skalierte Webanwendungen praktisch nicht geeignet.

Beide Einwände sind real. Keiner ist universell.

Was sich geändert hat: das Replikations-Ökosystem

2021 veröffentlichte Ben Johnson Litestream – ein Open Source Tool, das die WAL-Datei von SQLite nahezu in Echtzeit an S3-kompatiblen Objektspeicher streamt. Das Versprechen: Automatische Off-Site-Backups mit einer RPO unter einer Sekunde, ohne Änderungen am Anwendungscode oder einen Umstieg auf eine Client-Server-Datenbank. Litestream löst nicht die Einschränkung des einzelnen Schreibers, sondern das Problem der Disaster Recovery und der Sicherung, das SQLite für die Produktion unsicher erscheinen ließ. Für viele Anwendungsfälle ist das das drängendere Problem.

Fly.io ging mit LiteFS noch einen Schritt weiter – einem verteilten Dateisystem, das mit FUSE SQLite-Schreibvorgänge abfängt und auf Replica-Knoten repliziert. LiteFS bietet einen primären Knoten, der Schreibvorgänge akzeptiert, und Read Replicas, die ihm folgen – ähnlich der Streaming-Replikation von Postgres, aber für SQLite. Anwendungen, die Schreibvorgänge an den Primären und Lesevorgänge an beliebige Replicas routen können, profitieren von horizontaler Leseskalierung, ohne die Datenbank-Engine zu wechseln.

Das ambitionierteste Projekt ist Turso, basierend auf libSQL – einem Fork der SQLite-Codebasis, der ein Netzwerkprotokoll, Multi-Tenancy und Edge-Replikation hinzufügt. Turos Versprechen lautet „SQLite at the edge“: Jeder Benutzer bekommt einen Datenbank-Shard, der geografisch nahe bei ihm läuft, was die Latenz einer zentralen Datenbank eliminiert. Das Unternehmen sammelte 2023 in einer Series A 32 Millionen Dollar ein. libSQL ist Open Source; Turos Managed Service ist das kommerzielle Produkt. Cloudflares D1-Datenbankdienst verwendet eine ähnliche Architektur und bietet SQLite-kompatiblen Speicher als serverloses Primitive.

Das Performance-Argument

Für Anwendungen, bei denen die Datenbank auf demselben Rechner wie der Anwendungsserver läuft – was auf einen großen Anteil selbst gehosteter und kleiner bis mittlerer Anwendungen zutrifft – schneidet SQLite mit WAL-Modus bei Benchmarks oft schneller ab als Postgres oder MySQL bei leseintensiven OLTP-Workloads. Der Grund ist die Eliminierung der Netzwerklatenz: Eine lokale SQLite-Abfrage durchläuft keine TCP-Verbindung. Die Kosten einer Netzwerk-Round-Trip zu einem Postgres-Server, selbst auf localhost, betragen einige hundert Mikrosekunden. Bei hohen Abfragevolumen summiert sich das.

Das COST-Papier von 2015 („Scalability! But at what COST?“) machte einen ähnlichen Punkt im Kontext verteilter Graphverarbeitung: Ein einzelner Rechner mit gut optimiertem Single-Thread-Code übertraf oft verteilte Systeme wie Hadoop für Graphen, die in den RAM passen. Die Erkenntnis verallgemeinert sich: Verteile Systeme haben Overhead, und wenn Ihre Daten auf eine Maschine passen, zahlen Sie diesen Overhead möglicherweise ohne Nutzen.

SQLites WAL-Modus ist zudem extrem gut optimiert für hohe Leseparallelität. Benchmarks von Turso und unabhängigen Entwicklern zeigen durchgängig, dass SQLite auf bescheidener Hardware zehntausende Lesevorgänge pro Sekunde bewältigt – weit innerhalb des Rahmens der meisten Produktions-Webanwendungen.

Wer macht das tatsächlich?

37signals – das Unternehmen hinter Basecamp und Hey – war der lautstärkste öffentliche Befürworter. DHHs Blogbeitrag von 2023, in dem er argumentiert, dass SQLite mit Litestream für die meisten Webanwendungen ausreicht, sorgte für erhebliche Diskussionen. 37signals verwendet für einige seiner Infrastrukturen ein „Eine-Datenbank-pro-Kunde“-Modell, bei dem die Eigenschaft von SQLite, eine Datei pro Datenbank zu haben, zum Vorteil wird: Die Daten jedes Kunden sind in einer eigenen Datei isoliert, und Backups sind trivial einfach.

Viele Indie-Entwickler und kleine Teams sind aus ähnlichen Gründen zu SQLite gewechselt: einfacheres Betriebsmodell, kein separater Datenbankserver-Prozess zur Verwaltung, triviales Backup (Kopieren der Datei) und Leistung, die ihren Anforderungen genügt. Der Aufstieg von Plattformen wie Railway und Fly.io, die es einfach machen, persistentes SQLite neben einer Webanwendung zu betreiben, hat die betriebliche Hürde weiter gesenkt.

Wo es immer noch nicht sinnvoll ist

Die Einschränkung des einzelnen Schreibers ist eine reale Grenze. Anwendungen mit anhaltend hohem Schreibdurchsatz – Analytics-Ingestion-Pipelines, Hochfrequenzhandelssysteme, soziale Plattformen mit Millionen gleichzeitiger Schreiboperationen – benötigen tatsächlich eine Datenbank, die Schreibvorgänge auf mehrere Knoten verteilen kann. SQLite kann dies nicht nativ, und die darauf aufbauenden Replikationswerkzeuge ändern das grundlegende Schreibmodell nicht.

Sehr große Datensätze stellen ebenfalls Herausforderungen dar. SQLite unterstützt theoretisch Datenbanken bis zu 281 TB, aber die praktische Leistung bei Datenbanken über ein paar hundert Gigabyte lässt nach. Die VACUUM-, Autovacuum- und Partitionierungsfunktionen von Postgres sind ausgereift und im großen Maßstab gut verstanden; die entsprechenden Mechanismen von SQLite sind einfacher und bei großen Größen weniger kampferprobt.

Die Faustregel, die sich in der Community herauskristallisiert: Wenn Ihre Schreib-QPS unter ein paar tausend pro Sekunde liegt und Ihr Datensatz bequem auf eine einzige Festplatte passt, ist SQLite mit WAL eine ernsthafte Evaluierung wert. Wenn Sie Multi-Primary-Writes, synchrone Replikation über Rechenzentren hinweg oder zeilenbasierte Sicherheit mit komplexen Rollenhierarchien benötigen, ist Postgres immer noch das richtige Werkzeug.

Was sich geändert hat, ist die Betrachtungsweise. SQLite ist kein Spielzeug. Es ist eine ausgereifte, umfassend getestete Datenbank-Engine mit über zwei Jahrzehnten Produktionseinsatz in Kontexten, die weit anspruchsvoller sind als die meisten Webanwendungen. Die Frage ist nicht, ob SQLite ernst zu nehmen ist – sondern ob die spezifischen Einschränkungen Ihrer Anwendung zu seinem Modell passen. Für eine wachsende Zahl von Produktionssystemen tun sie das.