SQLite frisst die Welt

Die am weitesten verbreitete Datenbank, die du nie bereitgestellt hast

SQLite ist auf über einer Billion Geräten installiert. Dein Telefon hat es. Dein Browser hat es. Jede macOS-Installation wird damit ausgeliefert. Es betreibt die SMS-Datenbank auf Android, die Lesezeichenspeicherung in Firefox und die Foto-Metadaten auf deinem iPhone. Und dennoch wurde es bis vor kurzem von den meisten Backend-Entwicklern als Spielzeug behandelt – etwas für Prototypen, mobile Apps und lokale Skripte, nicht für den Betrieb eines echten Webdienstes.

Das ändert sich gerade rasant.

Was SQLite eigentlich ist

SQLite ist kein Datenbankserver. Es hat keine Netzwerkschicht, kein Authentifizierungssystem, keinen zu verwaltenden Daemon. Es ist eine C-Bibliothek, die eine einzelne Datei auf der Festplatte liest und schreibt. Du bindest sie in deine Anwendung ein und rufst sie direkt auf – keine Verbindungsstrings, keine Portnummern, keine zu verwaltenden Konfigurationsdateien.

Was es hat: vollständige ACID-Compliance, eine vollständige SQL-Implementierung (Fensterfunktionen, CTEs, JSON-Unterstützung, Volltextsuche), Sub-Millisekunden-Abfrageleistung für typische Arbeitslasten und ein so stabiles Dateiformat, dass das SQLite-Team die Abwärtskompatibilität bis 2050 garantiert. Die gesamte Datenbank ist eine Datei, die du kopieren, per E-Mail versenden oder in die Versionskontrolle aufnehmen kannst.

30 Jahre lang machte diese Kombination sie zur dominierenden Datenbank für eingebettete Anwendungsfälle – die Art, bei der du Persistenz ohne Infrastruktur benötigst. Aber "eingebettet" wird gerade neu definiert.

Warum der Produktionseinsatz nicht offensichtlich war

Der traditionelle Kritikpunkt an SQLite für Server-Workloads beruht auf zwei tatsächlichen Einschränkungen:

• Nebenläufigkeit: SQLite verwendet Dateisperren auf Dateiebene. Im WAL-Modus (WAL = Write-Ahead Log) blockieren Leser keine Schreiber und umgekehrt, aber du hast immer noch nur einen Schreiber gleichzeitig. Schreib-Workloads mit hoher Nebenläufigkeit stauen sich.
• Einzelner Rechner: Die Datenbank lebt in einem Dateisystem. Keine integrierte Replikation, kein Standby-Failover, keine Multi-Region-Schreibvorgänge. Wenn dein Server ausfällt, fällt auch deine Datenbank aus.

Das sind echte Einschränkungen. Aber für die meisten Webanwendungen sind sie irrelevant. Die durchschnittliche CRUD-App hat ein Lese-/Schreibverhältnis von 90% Lesevorgängen. Schreib-Nebenläufigkeit jenseits einiger Dutzend Anfragen pro Sekunde ist ein Problem, das die meisten Apps nie haben werden. Die Komplexität von Postgres – Verbindungspooling, Replikationsverzögerung, Standby-Failover, Schema-Migrationen über Replikate hinweg – existiert, um Probleme zu lösen, die in dem Maßstab, in dem die meisten Entwickler tatsächlich arbeiten, gar nicht existieren.

Die Distributed-SQLite-Welle

Das Ökosystem, das sich um SQLite für den Servereinsatz herum entwickelt hat, hat die verbleibenden Einschränkungen direkt angegangen. Drei Projekte treiben den Wandel voran.

Turso und LibSQL

LibSQL ist ein quelloffener Fork von SQLite, der von Turso gepflegt wird. Es fügt die Funktionen hinzu, die SQLite für Serverbereitstellungen unpraktisch machten: WAL-Modus-Replikation über HTTP, Fernzugriff über ein natives Protokoll, standardmäßig aktivierte ladbare Erweiterungen und Unterstützung für eingebettete Replikate – was bedeutet, dass deine Anwendung eine lokale SQLite-Kopie behalten kann, die von einem entfernten Primärserver synchronisiert wird. Du erhältst lokale Lese-Latenz mit entfernter Dauerhaftigkeit.

Das Ergebnis ist etwas, das sich wie eine serverlose Datenbank anfühlt, aber wie eine lokale Datei performt. Der gehostete Dienst von Turso ermöglicht es dir, Datenbanken in Sekunden zu erstellen und sie über Regionen hinweg zu replizieren, ohne eine Konfigurationsdatei anzufassen. Die kostenlose Stufe ist so großzügig, dass kleine Apps nie einen Cent bezahlen.

Cloudflare D1

Cloudflare D1 betreibt SQLite innerhalb von Cloudflare Workers am Edge. Wenn ein Worker in Frankfurt D1 abfragt, greift er auf eine SQLite-Instanz im selben Rechenzentrum zu, anstatt einen Ozean zu überqueren, um einen Postgres-Cluster in Virginia zu erreichen. Die Abfragelatenz, die in Hunderten von Millisekunden gemessen wurde, sinkt auf einstellige Werte.

D1 kümmert sich transparent um die Replikation. Du schreibst in ein Primärsystem, Cloudflare repliziert Lesevorgänge an Edge-Standorte. Die API ist Standard-SQL – du kannst drizzle-orm, kysely oder rohe Abfragen verwenden. Es ist SQLite mit einer globalen Leseschicht, die du nicht selbst bauen musstest.

Buns integriertes SQLite

Bun wird seit v1.1 mit einer nativen SQLite-Anbindung ausgeliefert – kein npm install, keine native Modulkompilierung, keine zu verwaltende better-sqlite3-Abhängigkeit. Du importierst bun:sqlite und öffnest eine Datenbank. Das war's. Für JavaScript-Entwickler, die leichtgewichtige Dienste oder CLI-Tools bauen, ist die Hürde für die Einführung von SQLite auf null gesunken.

Rails 8 machte es zum Standard

Das wichtigste Signal, dass SQLite eine Schwelle überschritten hat: Rails 8, veröffentlicht Ende 2024, liefert SQLite als Standarddatenbank für neue Anwendungen aus. Dies ist keine Prototypen-Behelfslösung – DHH und das Rails-Kernteam haben klargestellt, dass SQLite für die meisten Anwendungen die richtige Wahl ist, und sie haben in Werkzeuge investiert, um es produktionsreif zu machen: solid_queue für Hintergrundjobs auf SQLite, solid_cache für Caching und Litestream-basierte Backup-Integration.

Wenn das Framework, das das moderne Webanwendungsmuster definiert hat, standardmäßig eine dateibasierte Datenbank verwendet, hat sich die Diskussion in der Branche verschoben.

Das "SQLite für alles"-Argument

Das Argument ist nicht subtil: Für 80% der Webanwendungen brauchst du kein Postgres. Du brauchst keinen Verbindungspool. Du brauchst kein Replikat. Du brauchst eine Datenbank, die schnell, zuverlässig ist und keinen Systemadministrator für den Betrieb erfordert.

SQLite bietet dir:

• Null Konfiguration – kein zu startender Server, kein zu erstellender Benutzer, kein zu öffnender Port
• Sofortige Einrichtung – erstelle eine Datei, beginne SQL zu schreiben
• Triviale Backups – kopiere die Datei oder verwende Litestream für die kontinuierliche Replikation auf S3
• Hervorragende Leseleistung – Sub-Millisekunde für indizierte Abfragen auf Datenbanken bis zu mehreren zehn Gigabyte
• ACID-Garantien – Der WAL-Modus bietet dir gleichzeitige Lesevorgänge und Absturzsicherheit ohne Tuning

Die betriebliche Einfachheit potenziert sich. Wenn deine Datenbank eine Datei ist, ist deine Bereitstellung einfacher. Deine Entwicklungsumgebung entspricht exakt der Produktion. Das Debuggen ist einfacher. Du kannst die Datenbank im DB Browser for SQLite öffnen und die Daten direkt ansehen.

Wo es immer noch nicht passt

SQLite wird Postgres nicht überall ersetzen. Multi-Region-Schreibszenarien – bei denen du gleichzeitig Schreibvorgänge mit geringer Latenz von mehreren geografischen Standorten benötigst – sind mit SQLite wirklich schwierig. Du kannst es mit LibSQL-eingebetteten Replikaten und sorgfältigem Schreib-Routing umgehen, aber es ist nicht nativ. Schreib-Workloads mit hoher Nebenläufigkeit (denk an einen sozialen Feed mit Millionen gleichzeitiger Schreiber) werden auf den Einzelschreiber-Engpass stoßen.

Das Postgres-Ökosystem ist auch tiefer: bessere Erweiterungen (pgvector, PostGIS, TimescaleDB), ausgereiftere Beobachtbarkeitswerkzeuge, jahrzehntelanges Betriebswissen und Mehrversionen-Gleichläufigkeitskontrolle, die Schreibkonflikte eleganter handhabt. Wenn du ein System baust, bei dem der Schreibdurchsatz der Engpass ist, ist Postgres immer noch die richtige Wahl.

Der Wandel ist real

Das Muster hier ist nicht neu. SQLite entwickelte sich vom "Spielzeug" zur "ernsthaften Option", indem es die Probleme löste, die es in der eingebetteten Welt hielten – und das tat es nicht, indem es komplexer wurde, sondern indem es ein Ökosystem inspirierte, das die fehlenden Teile um es herum hinzufügte. LibSQL fügte Replikation hinzu. D1 fügte die Edge-Schicht hinzu. Litestream fügte kontinuierliche Backups hinzu. Bun beseitigte die Installationshürde.

Das Ergebnis ist eine Datenbank-Engine, die auf einer Billion Geräten produktionserprobt ist, keine Infrastruktur zum Ausführen benötigt und jetzt glaubwürdige Antworten auf die beiden Einwände hat, die sie früher disqualifizierten. Die Frage ist nicht, ob SQLite deine App bewältigen kann – sondern ob deine App wirklich das braucht, was Postgres bietet.

Für die meisten Apps ist die ehrliche Antwort nein.