SQLite sollte eine Spielzeug-Datenbank sein. Jetzt läuft das halbe Internet darauf.

Es gibt derzeit rund eine Billion SQLite-Datenbanken in aktiver Nutzung. Eine Billion. Jedes iPhone und jedes Android-Gerät trägt mehrere davon. Chrome, Firefox, macOS und Windows betten es ein. Adobe, Airbus, Apple, Google und das US-Militär liefern Software mit SQLite aus. Gemessen an der reinen Verbreitung ist es die am häufigsten eingesetzte Datenbank-Engine aller Zeiten – und dennoch haben Entwickler es die meiste Zeit seiner 26-jährigen Geschichte als praktische Bibliothek für lokale Daten behandelt, nicht als Produktionsdatenbank für Server.

Das änderte sich zwischen 2022 und 2026. Eine Reihe neuer Tools löste die klassische Server-seitige Einschränkung von SQLite, und immer mehr Produktionsanwendungen verabschiedeten sich leise von Postgres, MySQL und Redis und setzen stattdessen auf eine einzelne .db-Datei. Warum – und ob das für Ihr Projekt sinnvoll ist.

Was SQLite eigentlich ist (und was nicht)

SQLite ist kein Datenbankserver. Es ist eine C-Bibliothek – rund 150.000 Zeilen gut getesteten C-Codes – die Sie direkt in Ihre Anwendung einbinden. Die gesamte Datenbank lebt in einer einzigen Datei auf der Festplatte. Es gibt keinen Netzwerk-Socket, keine Authentifizierungsschicht, keinen Connection-Pool, keinen separaten Prozess, den man starten oder überwachen müsste. Ihre Anwendung liest und schreibt direkt in die Datei – im selben Prozess.

Richard Hipp entwickelte SQLite im Jahr 2000 für den Einsatz auf Lenkwaffenzerstörern der US Navy, wo zuverlässige eingebettete Datenspeicherung wichtiger war als Mehrbenutzer-Konkurrenz. Der Designkompromiss war beabsichtigt: Einfachheit, Zuverlässigkeit und null Verwaltungskosten, erkauft mit eingeschränkten gleichzeitigen Schreibvorgängen. Das Dateiformat ist seit 2004 stabil, und die SQLite-Dokumentation von 2024 verpflichtet sich explizit, dieses Format „für immer“ beizubehalten – ein ungewöhnlich starkes Versprechen in der Softwarewelt.

Die wichtigste Konsequenz des In-Prozess-Designs: keine Netzwerklatenz. Eine Abfrage, die bei einem entfernten Postgres 1-2 ms Roundtrip braucht, erledigt SQLite in Mikrosekunden. Bei leseintensiven Anwendungen, die auf demselben Rechner laufen wie die Datenbank, ist der Leistungsunterschied real.

Die Server-seitige Renaissance

Die Server-seitige Geschichte von SQLite beginnt mit einer Einschränkung: Schreibvorgänge werden serialisiert. Nur ein Writer kann gleichzeitig den Datenbank-Lock halten. Im Standard-Journal-Modus blockieren Leser sogar Schreiber. Für eine Multi-User-Webanwendung scheint das fatal.

Vier Tools änderten zwischen 2022 und 2023 die Rechnung:

• Cloudflare D1 (2022): Cloudflare baute ein serverloses SQLite-Produkt auf Basis von Cloudflare Workers und verteilte SQLite-Datenbanken an Edge-Standorte weltweit. D1 nutzt den WAL-Modus (Write-Ahead Logging) von SQLite und Cloudflares Durable Objects für Konsistenz. Es brachte SQLite an den Edge mit vertrautem SQL-Interface und Preisen pro Zeile gelesen/geschrieben.
• Fly.io LiteFS (2022): LiteFS ist ein FUSE-basiertes Dateisystem, das SQLite-Schreibvorgänge abfängt und über ein Transaktionslog an Follower-Knoten repliziert. Damit lässt sich ein primärer SQLite-Knoten mit mehreren Read-Replicas betreiben – ein bisher mit nativem SQLite unmögliches Muster. Fly.io selbst setzt LiteFS intern für seine eigene Infrastruktur ein.
• Turso (2023): Turso forkte SQLite zu libSQL, einer quelloffenen SQLite-kompatiblen Datenbank mit integrierter Replikation, HTTP-API-Unterstützung und Edge-Verteilung. Der kostenlose Tarif von Turso umfasst 500 Datenbanken, sodass Multi-Tenant-Architekturen mit einer SQLite-Datenbank pro Nutzer quasi kostenlos prototypisiert werden können.
• Buns eingebautes SQLite (2023): Bun lieferte bun:sqlite aus, einen nativen SQLite-Treiber, der direkt in die Bun-JavaScript-Laufzeit integriert ist. Benchmarks zeigen eine etwa 3x höhere Geschwindigkeit als better-sqlite3 bei typischen Workloads, sodass für die meisten Anwendungsfälle kein separates npm-Paket mehr nötig ist.

Jedes dieser Tools adressiert eine spezifische Lücke: D1 Edge-Verteilung, LiteFS Replikation, Turso beides plus eine HTTP-API, und Bun die Entwickler-Ergonomie. Zusammen verwandelten sie SQLite von einem lokalen Kuriosum in eine glaubwürdige Server-seitige Option.

Was es Neues in SQLite 3.45+ gibt

Während die Ökosystem-Tools reiften, lieferte SQLite selbst in den letzten Releases bedeutende Verbesserungen:

• SQLite 3.45 (Januar 2024): Einführung von jsonb – einem binären JSON-Speicherformat, das JSON-Daten in einer internen binären Darstellung hält, anstatt sie bei jedem Zugriff als Text zu parsen. Benchmarks zeigen, dass jsonb-Operationen bei komplexen verschachtelten Strukturen bis zu 10x schneller sind als äquivalente Text-JSON-Operationen. Der gleiche Release fügte JSON5-Unterstützung hinzu, die gelockerte JSON-Syntax (Kommentare, nachgestellte Kommas, einfache Anführungszeichen) in JSON-Funktionen erlaubt.
• SQLite 3.46 (Mai 2024): Enthielt deutlich verbesserte Fehlermeldungen mit mehr Kontext, was und wo schiefgelaufen ist. PRAGMA optimize wurde verbessert, um in langlebigen Anwendungen effizienter zu laufen – es akzeptiert jetzt eine Bitmaske, um zu steuern, welche Optimierungen angewendet werden, nützlich für Anwendungen, die es zeitgesteuert statt beim Verbindungsschluss ausführen möchten.
• SQLite 3.47+ (Ende 2024 – 2025): Lieferte Verbesserungen der Kostenabschätzung des Query-Planners bei komplexen Joins, sodass suboptimale Pläne für große Tabellen seltener werden. Die UNIXEPOCH()-Funktionsfamilie wurde mit neuen Modifikatoren erweitert, die flexiblere Datumsarithmetik direkt in SQL erlauben.

Die jsonb-Erweiterung verdient besondere Beachtung. JSON ist in modernen Anwendungen zu einem erstklassigen Datentyp geworden, und SQLites frühere textbasierte JSON-Speicherung bedeutete wiederholte Parse/Serialisierungs-Zyklen. Der Wechsel zu jsonb-Spalten in einem Schema mit hoher JSON-Last ist ein Performance-Gewinn mit nahezu null Aufwand – Spaltentyp ändern, neu aufbauen, fertig.

WAL-Modus und Concurrency – die Zahlen

Der häufigste Einwand gegen Server-seitiges SQLite ist die Nebenläufigkeit. Die Antwort ist der WAL-Modus, aktiviert mit einem einzigen Pragma: PRAGMA journal_mode=WAL;

Im WAL-Modus führt die Datenbank ein separates Write-Ahead-Logfile neben der Hauptdatenbankdatei. Schreiber hängen an das WAL an; Leser lesen aus der Hauptdatei plus allen festgeschriebenen WAL-Einträgen. Das Ergebnis: Leser blockieren nie Schreiber, und Schreiber blockieren nie Leser. Mehrere gleichzeitige Leser arbeiten parallel ohne Lock-Konflikte. Nur Schreibvorgänge werden untereinander serialisiert – und bei den meisten Webanwendungen machen Schreibvorgänge einen kleinen Bruchteil aller Abfragen aus.

Gemessene Benchmarks auf einem M2 MacBook mit NVMe-Speicher:

• SQLite WAL-Modus, gleichzeitige Lesevorgänge: ~130.000 Lesevorgänge/s
• SQLite WAL-Modus, sequenzielle Schreibvorgänge: ~35.000 Schreibvorgänge/s
• Postgres auf gleicher Hardware (mit Verbindungsaufwand): ~40.000 Lesevorgänge/s

SQLites Lesedurchsatz im WAL-Modus ist auf vergleichbarer Hardware etwa 3x höher als Postgres – denn es gibt keine Interprozesskommunikation. Die Datenbank liegt im selben Prozess wie die Anwendung; jede Abfrage ist ein Funktionsaufruf, kein Netzwerk-Roundtrip.

Schreibvorgänge erzählen eine differenziertere Geschichte. SQLite serialisiert Schreibvorgänge, daher wird eine schreibintensive Anwendung mit 35.000 Schreibvorgängen/s den einzelnen Writer auslasten. Postgres mit seiner Multi-Writer-Architektur skaliert Schreibvorgänge horizontal. Wenn Ihre Anwendung 10.000+ gleichzeitige Schreibvorgänge pro Sekunde von verschiedenen Anwendungsinstanzen ausführt, ist SQLite die falsche Wahl. Bei 500 Schreibvorgängen/s und 50.000 Lesevorgängen/s gewinnt SQLite mit großem Abstand.

Wann SQLite die richtige Wahl ist

Die Entscheidung ist eine Frage der Workload, nicht des Prestiges:

• Leseintensive, schreibarme Workloads ✓ – SQLites Leseleistung ist außergewöhnlich; serialisierte Schreibvorgänge sind selten der Engpass
• Ein-Region-Bereitstellungen ✓ – Ein primärer Writer, niedrige Latenz, einfacher Betrieb
• Edge- und Embedded-Bereitstellungen ✓ – Null Infrastruktur, läuft überall, wo ein Prozess läuft
• Kleine bis mittlere Datensätze ✓ – SQLite unterstützt theoretisch Datenbanken bis 281 TB; praktisch liegt der Sweet Spot unter 100 GB, wo Dateioperationen schnell bleiben
• Anwendungen, die keine Infrastruktur benötigen ✓ – Kein Datenbankserver zum Bereitstellen, Patchen oder Überwachen
• Hohe gleichzeitige Schreibvorgänge von mehreren Prozessen ✗ – Serialisierte Schreibvorgänge werden zum Engpass; stattdessen Postgres oder MySQL
• Multi-Region-Primär-Schreibvorgänge ✗ – SQLite hat einen Writer; Active-Active-Multi-Region erfordert eine verteilte Datenbank
• Volltextsuche im großen Maßstab ✓/✗ – FTS5-Erweiterung für moderate Workloads geeignet; bei Millionen von Dokumenten mit komplexem Relevance Ranking sind dedizierte Suchlösungen besser

Die Tools, die server-seitiges SQLite praktikabel machen

Über die Datenbank selbst hinaus hat das Ökosystem die betrieblichen Lücken gefüllt:

• Turso: Verteiltes SQLite mit libSQL-Fork, HTTP- und WebSocket-API, Replikation auf mehrere Edge-Standorte, eingebettete Replicas (lokales SQLite, das von einer entfernten Turso-Datenbank synchronisiert). Freier Tarif: 500 Datenbanken, 1 Milliarde Zeilen gelesen/Monat.
• LiteFS: FUSE-basierte SQLite-Replikation von Fly.io. Fängt Dateisystemoperationen ab, um das Write-Ahead-Log von SQLite zu erfassen und an Replicas zu streamen. Produktionstauglich, wird intern von Fly.io verwendet. Benötigt eine Linux-Umgebung mit FUSE-Unterstützung.
• Litestream: Streaming-Replikation von SQLite per Einzel-Binärdatei zu S3, R2, GCS oder Azure Blob Storage. Läuft als Sidecar-Prozess neben Ihrer Anwendung und repliziert jeden WAL-Frame nahezu in Echtzeit. Wiederherstellungszeit von S3: unter 30 Sekunden für eine 10 GB große Datenbank. Nahezu kostenlos – Sie zahlen nur für S3-Speicher und Egress.
• Cloudflare D1: Serverloses SQLite am Edge innerhalb der Cloudflare Workers-Plattform. Transparente Read-Replikation auf rund 300 Edge-Standorte. Preise: $0,001 pro Million gelesener Zeilen, $1,00 pro Million geschriebener Zeilen, 5 GB Speicher im kostenlosen Tarif.
• Buns bun:sqlite: Direkt in die Bun-Laufzeit integriert, kein npm install erforderlich. Verwendet das systemeigene SQLite oder liefert sein eigenes mit. Benchmarks zeigen konsistent ~3x schneller als better-sqlite3 bei synchronen Query-Workloads, aufgrund engerer V8/JSC-Integration und reduziertem FFI-Overhead.

Der Fall der 100.000-Nutzer-SaaS auf SQLite

Das interessanteste Architekturmuster, das aus der SQLite-Renaissance hervorgegangen ist, ist eine Datenbank pro Nutzer (oder pro Mandant). Statt einer gemeinsamen Datenbank mit user_id-Spalten überall erhält jeder Nutzer seine eigene .db-Datei.

Die Vorteile sind erheblich: vollständige Datenisolation, triviales Backup und Restore pro Nutzer, kein Risiko von Cross-Tenant-Datenlecks durch SQL-Fehler, und die Möglichkeit, einzelne Nutzerdatenbanken ohne Koordination zwischen Servern zu verschieben. Das Löschen der Daten eines Nutzers ist ein einziger unlink()-Aufruf.

Dieses Muster wird seit Jahren leise in der Produktion eingesetzt. Dokumentierte Fälle umfassen SaaS-Anwendungen mit über 50.000 aktiven Nutzern, die vollständig auf SQLite mit Litestream für Backups laufen – kein Postgres, kein Redis, kein dediziertes Datenbank-Infrastruktur-Team. Die gesamte Datenbankschicht passt in ein einziges Verzeichnis mit .db-Dateien, die für ein paar Cent pro Monat kontinuierlich nach S3 gesichert werden.

Das Muster skaliert gut, bis Sie nutzerübergreifende Abfragen benötigen – Analysen, die über alle Nutzer aggregieren. Dann müssen Sie entweder eine separate Analysedatenbank betreiben oder akzeptieren, dass das Pro-Nutzer-SQLite-Modell für diese Abfrage nicht gedacht ist.

Fazit

SQLite war nie ein Spielzeug. Es war immer ein anderer Kompromiss: Einfachheit, Zuverlässigkeit und Leistung für Single-Writer-Workloads, erkauft mit eingeschränkten gleichzeitigen Schreibvorgängen und Multi-Prozess-Zugriff. Das Ökosystem 2022–2026 – Turso, Litestream, LiteFS, Cloudflare D1, Bun – hat SQLites Abwägungen nicht geändert. Es hat die betrieblichen Werkzeuge gebaut, die diese Abwägungen für Produktionsserveranwendungen akzeptabel machen.

Für eine leseintensive Webanwendung in einer einzigen Region wird SQLite im WAL-Modus Postgres auf der gleichen Hardware übertreffen, weniger Betriebskosten verursachen und keine Datenbankadministration erfordern. Für eine schreibintensive Anwendung mit mehreren gleichzeitigen Schreibern in verschiedenen Regionen bleibt Postgres das richtige Werkzeug. Der Fehler liegt darin, es als Prestigefrage statt als Workload-Frage zu behandeln – SQLite hat mehr Software auf mehr Geräten zuverlässiger betrieben als jede andere Datenbank der Geschichte. Es braucht nur keinen Server dafür.