Magazin
SQLite will kein Datenbankserver sein – und genau deshalb ist es interessant
SQLite konkurriert nicht mit PostgreSQL, sondern mit selbst gebauten Dateien. Das ist eine erstaunlich nützliche Architekturentscheidung.
SQLite ist eine eingebettete Datenbank. Sie läuft als Teil einer Anwendung, verarbeitet strukturierte Daten mit der Abfragesprache SQL und speichert sie gewöhnlich in einer einzigen Datei. PostgreSQL und MySQL funktionieren dagegen als eigenständige Datenbankserver, mit denen Anwendungen über einen separaten Dienst kommunizieren.
Für lokale Anwendungsdaten, Analysewerkzeuge, Geräte oder übertragbare Datenpakete kann eine abfragbare Datei einfacher sein als ein Verzeichnis voller selbst entworfener JSON-Textdateien – und erheblich einfacher als ein zusätzlicher Server. Die SQLite-Projektseite formuliert die Konkurrenz deshalb ungewöhnlich treffend: SQLite konkurriere eher mit dem Öffnen selbst gebauter Dateien als mit PostgreSQL.
Die Grenze ist klar: Pro Datenbankdatei kann nur ein Vorgang zur selben Zeit schreiben; Leser dürfen parallel zugreifen. Viele direkte Zugriffe über eine im Netzwerk liegende Dateiablage oder viele gleichzeitige Änderungen sprechen daher für einen Datenbankserver.
Die Zuverlässigkeit fällt trotzdem nicht vom Himmel. In seiner Testdokumentation zu SQLite 3.42 nennt das Projekt historisch rund 590-mal so viel Testcode und Testskripte wie eigentlichen C-Quellcode. Geprüft wurden unter anderem Speichermangel, Schreibfehler, Abstürze, Stromausfälle und beschädigte Datenbanken.
Die brauchbare Faustregel lautet nicht „SQLite ist nur für Spielzeug“. Sie lautet: Liegen Anwendung und Daten auf demselben Rechner und gibt es wenige gleichzeitige Schreibvorgänge? Dann muss sich zuerst der zusätzliche Server rechtfertigen.
Quellen
- SQLite: Appropriate Uses For SQLite, zuletzt aktualisiert am 31. Mai 2025
- SQLite: How SQLite Is Tested, Kennzahlen zu SQLite 3.42 vom 16. Mai 2023
Quellenstand: 5. September 2026.