SQLite ist die Datenbank, mit der die Cloud nicht gerechnet hat – und sie setzt sich trotzdem durch

Weltweit gibt es rund eine Billion aktive SQLite-Installationen. Diese Zahl aus der eigenen Dokumentation des SQLite-Projekts ist keine Marketing-Schätzung – sie ist eine architektonische Realität. Jedes iPhone wird mit SQLite ausgeliefert. Jedes Android-Gerät nutzt es. Firefox verwendet es für Verlauf, Lesezeichen und Cookies. Chrome setzt es als Datenbank-Backend ein. Skype, Dropbox, iTunes, VLC und die gesamte Adobe Creative Suite betten es ein. Die Library of Congress empfiehlt es als Archivierungsformat. SQLite ist, gemessen an der Anzahl der Installationen, die am weitesten verbreitete Datenbank-Engine überhaupt – und bis vor Kurzem hielten die meisten Entwickler es für etwas, das in mobilen Apps steckt, nicht für ernsthafte Infrastruktur.

Diese Einstufung ist heute überholt. Im Jahr 2026 läuft SQLite im globalen Edge-Netzwerk von Cloudflare, betreibt verteilte Anwendungen über Turso's libSQL-Fork und bildet das Fundament einer lokalen Anwendungsarchitektur, die ernsthafte Ingenieursaufmerksamkeit auf sich zieht. Die Datenbank, die dreißig Jahre lang als „nicht produktionsreif" galt, definiert leise neu, was Produktion bedeutet.

Was SQLite eigentlich ist

SQLite ist eine C-Bibliothek – rund 155.000 Zeilen – die eine vollständige SQL-Datenbank-Engine in einer einzigen Datei mit null externen Abhängigkeiten, keinem Server-Prozess und keiner Konfiguration implementiert. Eine Datenbank ist einfach eine Datei auf der Festplatte. Das Öffnen erfordert keinen Verbindungsstring, keinen Authentifizierungs-Handshake, keinen laufenden Daemon, zu dem man sich verbindet. Sie binden die Bibliothek ein, öffnen die Datei und führen SQL aus. Das ist der gesamte Setup.

Trotz seiner Einfachheit ist SQLite vollständig ACID-konform. Schreibvorgänge sind atomar; gleichzeitige Lesevorgänge werden durch den WAL-Modus (Write-Ahead Log) unterstützt; das On-Disk-Format ist seit 2004 stabil und vollständig abwärtskompatibel. Es unterstützt vollständiges SQL-92 mit den meisten Features von SQL:1999, einschließlich Window Functions, CTEs und JSON-Operatoren, die in neueren Versionen hinzugefügt wurden. Das Projekt wird von einem kleinen Team unter Public-Domain-Widmung gepflegt – keine Lizenz, kein Urheberrecht, keine Contributor Agreements.

Richard Hipp startete es im Jahr 2000 für das Lenkwaffenzerstörer-Programm der US Navy, wo das Fehlen eines Datenbankadministrators eine Design-Beschränkung war, kein Versehen. Dieser Ursprung definiert alles an SQLite: Es wurde für Umgebungen entwickelt, in denen man sich keinen Server, keinen DBA und keine Netzwerkkonnektivität leisten kann. Diese Einschränkungen, so stellt sich heraus, beschreiben die Edge-Computing-Umgebung fast perfekt.

SQLite at the edge: Cloudflare D1, Turso und LiteFS

Cloudflare D1, das 2023 allgemein verfügbar wurde und 2024–2025 massiv erweitert wurde, ist SQLite, das innerhalb von Cloudflare Workers an über 300 Edge-Standorten weltweit läuft. Wenn ein Worker eine D1-Abfrage ausführt, greift er auf eine SQLite-Datei zu, die am nächstgelegenen Edge-Knoten co-lokalisiert ist. Lesevorgänge sind sub-Millisekunden-schnell. Die Datenbank kann ohne Provisioning auf 10 GB pro Datenbank skaliert werden – Sie erstellen eine D1-Datenbank mit einem CLI-Befehl und sie ist sofort global verfügbar.

D1 löst das Write-Problem durch ein Primary-Replica-Modell: Schreibvorgänge gehen an einen primären Standort und werden asynchron an alle Edge-Knoten repliziert. Für read-heavy Workloads – was die meisten Web-Anwendungen beschreibt – ist der Latenzvorteil gegenüber einer Single-Region-PostgreSQL-Instanz erheblich. Cloudflare gibt an, dass D1 Anfang 2026 monatlich über 50 Milliarden gelesene Zeilen über seine Kundenbasis hinweg bedient.

Turso, aufgebaut auf libSQL – einem Open-Source-Fork von SQLite, der von ChiselStrike gepflegt wird – verfolgt einen anderen architektonischen Ansatz. libSQL erweitert SQLite um native Replikation, Server-Modus und HTTP-API-Unterstützung, bleibt dabei aber wire-kompatibel mit Standard-SQLite-Dateien. Turso bietet eingebettete Replicas: Ihre Anwendung führt ein lokales SQLite-Replica, das mit einer zentralen Datenbank synchron bleibt, was lokale Lesevorgänge mit null Latenz und eventual consistency bei Schreibvorgängen ermöglicht. Das Modell ist explizit für Edge-Runtimes und Serverless-Funktionen ausgelegt, bei denen die Latenzkosten eines entfernten Datenbankaufrufs unerschwinglich sind.

LiteFS, entwickelt von Ben Johnson und jetzt unter dem Dach von Fly.io gepflegt, verfolgt einen FUSE-basierten Ansatz zur SQLite-Replikation. Es fängt Dateisystem-Schreibvorgänge auf OS-Ebene ab und repliziert das Write-Ahead-Log von SQLite über eine Consensus-Schicht auf andere Knoten. Anwendungen erfordern keine Code-Änderungen – LiteFS sitzt zwischen der Anwendung und dem Dateisystem und synchronisiert transparent SQLite-Datenbanken über einen Fly.io-Cluster. Fly.io Volumes, die persistente Speicherschicht für Fly-Apps, in Kombination mit LiteFS bietet Entwicklern eine verteilte SQLite-Umgebung mit automatischem Failover und Replikation über mehrere Regionen.

SQLite-over-HTTP und die neuen Zugriffsmuster

Eine der interessanteren Entwicklungen im SQLite-Ökosystem ist das Aufkommen von HTTP-basierten Zugriffsschichten, die es eher wie eine traditionelle Client-Server-Datenbank verhalten, ohne seine Embedded-Vorteile aufzugeben. Der Server-Modus von libSQL bietet eine WebSocket- und HTTP-API, mit der Clients aus der Ferne verbinden können – das bedeutet, dass eine auf einem Server laufende SQLite-Datenbank von einem Browser, einer mobilen App oder einer Serverless-Funktion mit Standard-HTTP-Semantiken abgefragt werden kann.

Das ist wichtig, weil es SQLite für Umgebungen freischaltet, in denen die direkte Einbettung der Bibliothek nicht möglich ist. Eine Next.js-Anwendung, die auf Vercel deployed ist, kann keine native SQLite-Bibliothek bündeln – aber sie kann HTTP-Anfragen an eine Turso-Datenbank stellen und SQL-Abfrageergebnisse als JSON zurückerhalten. Die Developer Experience ist nahezu identisch mit der Abfrage von Postgres über einen Connection Pool, aber die zugrunde liegende Engine ist SQLite, mit all der operativen Einfachheit, die das mit sich bringt.

Bun, die JavaScript-Laufzeitumgebung, die als schnellere Node.js-Alternative an Bedeutung gewinnt, wird mit nativer SQLite-Unterstützung durch sein bun:sqlite-Modul ausgeliefert – kein npm install erforderlich, keine native Modulkompilierung, kein node-gyp. const db = new Database("mydb.sqlite"); ist der gesamte Setup. Die von Bun für seine SQLite-Implementierung genannten Leistungszahlen – über 4 Millionen Lesevorgänge pro Sekunde auf einem Laptop – spiegeln wider, wie schnell eine Datenbank ohne Netzwerk-Overhead sein kann, wenn sie im selben Prozess wie Ihr Anwendungscode läuft.

Lokale Architektur und der Aufstieg von CRDTs

Die lokale Bewegung in der Webentwicklung basiert auf einer spezifischen Behauptung: dass die richtige Architektur für die meisten Anwendungen eine ist, bei der die Datenbank auf dem Client lebt, Lesevorgänge sofort erfolgen, weil sie lokalen Speicher nutzen, und die Synchronisierung mit einem Server im Hintergrund passiert. Die User Experience ist schneller, Offline-Fähigkeit ist integriert, und der Server wird zu einem Sync-Relay statt zu einem Query-Nadelöhr.

SQLite ist die natürliche Wahl für diese Architektur, weil es überall läuft – im Browser via WebAssembly (wa-sqlite, sql.js), in Electron-Apps nativ, auf Mobilgeräten über das eingebaute SQLite der Plattform, und auf Edge-Knoten durch D1 oder Turso. Dieselben SQL-Abfragen funktionieren in all diesen Umgebungen auf Dateien, die grundlegend miteinander kompatibel sind.

Das harte Problem bei lokalen Architekturen ist die Konfliktlösung: Wenn zwei Clients beide offline in ein lokales SQLite-Replica schreiben, wie führt man diese Schreibvorgänge zusammen, wenn sie sich wieder verbinden? Hier kommen CRDTs (Conflict-free Replicated Data Types) ins Spiel. cr-sqlite, eine SQLite-Erweiterung von Matt Wonlaw bei Vlcn.io, implementiert CRDT-Semantiken direkt in SQLite, indem es Standard-SQL-Tabellen mit einer Lamport-Uhr und einer Merge-Funktion instrumentiert. Zwei cr-sqlite-Datenbanken können deterministisch ohne zentrale Autorität zusammengeführt werden. Jeder Konflikt auf Zeilenebene wird durch die CRDT-Merge-Regeln gelöst, nicht durch einen Server, der entscheidet, welcher Schreibvorgang gewinnt.

Diese Kombination – SQLite für Speicher, CRDTs für Merge-Semantiken, ein Sync-Relay für Konnektivität – ist die Architektur hinter Tools wie ElectricSQL, Replicache und Zero (vom Rocicorp-Team, das Replicache gebaut hat). Es ist nicht mehr rein experimentell: Linear, das Projektmanagement-Tool, verwendet eine lokale SQLite-basierte Architektur für seine Desktop-App und führt sein flottes Gefühl speziell darauf zurück, dass jede Interaktion auf eine lokale Datenbank trifft und nicht auf eine Remote-API.

Developer Tooling im Jahr 2026

Das ORM- und Tooling-Ökosystem hat mit SQLites erweiterter Rolle Schritt gehalten. Drizzle ORM, eines der am schnellsten wachsenden TypeScript-ORMs, behandelt SQLite als First-Class-Ziel neben PostgreSQL und MySQL – mit spezifischen Adaptern für better-sqlite3, Buns nativem SQLite, libSQL, D1 und Turso. Drizzles Type Inference bedeutet, dass Ihr SQLite-Schema Ihre TypeScript-Typen mit null Runtime-Overhead antreibt.

Prisma hat 2024 mit seinem Driver-Adapters-Modell D1-Unterstützung hinzugefügt, sodass die Prisma-Query-Engine über die D1-HTTP-API gegen Cloudflare D1 laufen kann. Die Prisma-Schema-Definition bleibt identisch, egal ob Sie Postgres oder D1 anvisieren; nur die Client-Initialisierung ändert sich. better-sqlite3, das Node.js-SQLite-Binding von Joshua Wise, bleibt die erste Wahl für synchronen, leistungsstarken SQLite-Zugriff in serverseitigem Node.js – sein synchrones API-Design ist eine bewusste Entscheidung, die SQLites eigener synchroner Natur entspricht und den Async-Overhead vermeidet, der die meisten Datenbanktreiber plagt.

Wo SQLite wirklich schwächelt

SQLites Single-Writer-Modell ist seine bedeutendste architektonische Einschränkung. Es kann jeweils nur eine Write-Transaction ausgeführt werden – selbst im WAL-Modus, der gleichzeitige Lesevorgänge neben einem einzelnen Schreiber erlaubt, können nicht zwei Prozesse gleichzeitig in dieselbe SQLite-Datenbank schreiben, ohne Serialisierung. Für Anwendungen mit hohem gleichzeitigem Write-Durchsatz – eine Bestenliste, die tausende Score-Updates pro Sekunde erhält, ein Nachrichtensystem mit gleichzeitigen Schreibvorgängen von tausenden verbundenen Clients – ist SQLites Write-Modell eine harte Grenze.

Der WAL-Modus hilft erheblich bei read-heavy Workloads mit gelegentlichen Schreibvorgängen: Leser blockieren nie Schreiber und Schreiber blockieren nie Leser. Aber WAL ändert nichts an der grundlegenden Single-Writer-Beschränkung. Wenn Ihr Engpass die Write-Konkurrenz ist, benötigen Sie eine Datenbank mit einem Lock Manager, der dafür ausgelegt ist – PostgreSQL, MySQL oder ein verteiltes System wie CockroachDB.

Es gibt auch keine integrierte Replikation. Standard-SQLite hat kein Konzept von Primary/Replica, kein WAL-Shipping, keine logischen Replikationsslots. Jede Replikationslösung im Ökosystem – LiteFS, Turso's eingebettete Replicas, cr-sqlite – ist eine von Drittanbietern auf SQLite aufgesetzte Schicht. Das bedeutet, dass Replikations-Setups mehr operative Komplexität mit sich bringen, als es den Anschein hat: Sie verwalten zwei Systeme (SQLite plus die Replikationsschicht) statt einem. Und die Konsistenzgarantien variieren: Turso's eingebettete Replicas sind eventual consistent, nicht strong consistent – ein Schreibvorgang auf einem Replica kann auf einem anderen nicht sofort sichtbar sein.

Die Datenbankdateigröße wird ebenfalls zu einem Faktor im großen Maßstab. SQLite handhabt routinemäßig Datenbanken im zweistelligen Gigabyte-Bereich und wurde bis zu Hunderten von Gigabyte getestet, aber bei dieser Größenordnung verlieren Sie etwas von der operativen Einfachheit, die SQLite attraktiv macht. Das Verschieben einer 50 GB großen SQLite-Datei zu Backup-Zwecken ist eine andere Sache als die Replikation über einen Log-basierten Stream.

Wann man SQLite wählt und wann nicht

SQLite ist die richtige Wahl, wenn Ihr Read-to-Write-Verhältnis hoch ist, wenn Sie null operativen Overhead wünschen, wenn Sie für Edge oder lokale Architekturen bauen, oder wenn Sie ein Developer Tool, CLI oder eine eingebettete Anwendung ausliefern, bei der ein Datenbankserver absurd wäre. D1 und Turso haben es für Produktions-Webanwendungen mit globalen Nutzern nutzbar gemacht, vorausgesetzt diese Anwendungen sind read-heavy und können eventual consistency bei Schreibvorgängen tolerieren.

PostgreSQL bleibt die richtige Wahl, wenn Sie starke Write-Koinzidenz, Row-Level-Locking, komplexe Replikationstopologien oder das tiefe Erweiterungs-Ökosystem (PostGIS, pgvector, TimescaleDB) benötigen, das Postgres in dreißig Jahren aufgebaut hat. MySQL und MariaDB besetzen ähnliches Terrain. Eine verteilte Datenbank wie CockroachDB oder PlanetScale ist angebracht, wenn Sie horizontales Write-Scaling mit strong consistency Garantien über Regionen hinweg benötigen – ein Anwendungsfall, für den SQLite nie ausgelegt war.

Die interessantere Frage für 2026 ist nicht „SQLite vs. Postgres", sondern „wo gehört jeweils in dasselbe System?" Viele Produktionsarchitekturen verwenden inzwischen beide: SQLite am Edge für benutzerspezifische, schreibarme Daten (Session-State, Präferenzen, benutzerspezifische Feeds) und Postgres im Zentrum für gemeinsame, schreibintensive Daten (Transaktionen, Inventar, Nachrichten). Die Datenbank, mit der die Cloud nicht gerechnet hat, hat ihren Platz im Stack gefunden – nicht indem sie ersetzte, was davor kam, sondern indem sie die Fälle behandelt, in denen das Aufsetzen eines Postgres-Clusters immer die falsche Antwort war.