Was ist SQLite? Die eingebettete SQL-Datenbank erklärt

SQLite ist eine Datenbank direkt in deinem Programm

Die meisten Datenbanken, von denen du schon gehört hast – MySQL, Postgres, SQL Server – laufen als eigenständiger Prozess. Du startest einen Server, der lauscht auf einem Port, und deine Anwendung verbindet sich übers Netzwerk, um Anfragen zu stellen. SQLite wirft dieses ganze Modell über den Haufen.

SQLite ist eine Bibliothek. Du bindest sie in dein Programm ein, und schon hast du eine SQL-Datenbank, die in einer einzigen Datei auf der Festplatte liegt. Kein Server, kein Port, kein Daemon, kein pg_ctl start. Deine Anwendung öffnet eine Datei – und diese Datei ist die Datenbank.

sqlite3 mydata.db

Mit diesem Befehl öffnest du eine Datei namens mydata.db (bzw. legst sie an, falls sie noch nicht existiert) und landest direkt im SQL-Prompt. Alles, was du danach anlegst – Tabellen, Zeilen, Indizes – wandert in genau diese eine Datei. Kopierst du sie auf einen anderen Rechner, ist die komplette Datenbank dabei. Löschst du sie, ist die Datenbank weg.

Ein kurzer Streifzug durch SQL

Das SQL selbst sieht aus wie überall sonst. Wer schon mal mit einer anderen Datenbank gearbeitet hat, wird sich sofort heimisch fühlen:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

Standard-SQL — CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite unterstützt genau die Teile des SQL-Standards, die du im Alltag wirklich brauchst, dazu moderne Annehmlichkeiten wie CTEs, Window Functions und JSON-Funktionen. Die Unterschiede zu Postgres oder MySQL betreffen vor allem die Datentypen und ein paar Syntax-Eigenheiten — dazu kommen wir später.

Was „eingebettet" und „serverlos" wirklich bedeuten

Bei SQLite tauchen zwei Begriffe ständig auf. Die sollten wir sauber klären.

Eingebettet heißt: SQLite läuft im selben Prozess wie deine Anwendung. Es gibt keinen separaten Datenbankprozess. Wenn dein Python-Skript sqlite3.connect("data.db") aufruft, läuft die SQL-Engine innerhalb deines Python-Prozesses und liest und schreibt direkt in die Datei.

Serverlos heißt: Es gibt keinen Server, den du installieren, konfigurieren, starten, absichern oder sichern musst. Vergleich mal die Schritte, um eine Datenbank in Betrieb zu nehmen:

• Postgres: Postgres installieren, den Dienst starten, einen User anlegen, eine Datenbank anlegen, pg_hba.conf konfigurieren, Verbindung über TCP aufbauen.
• SQLite: eine Datei öffnen.

Das ist der ganze Unterschied. Weniger Power, dafür viel weniger Drumherum.

Die ganze Datenbank steckt in einer einzigen Datei

Das ist der Punkt, der die Leute überrascht. Das Dateiformat ist dokumentiert und stabil — eine .db-Datei (oder .sqlite, oder .sqlite3, die Endung ist reine Konvention), die du:

• per E-Mail an Kolleginnen und Kollegen schicken kannst.
• in git einchecken kannst (zumindest, wenn sie klein ist).
• mit cp kopieren kannst — fertig ist das Backup.
• mit jedem SQLite-Tool auf jedem Betriebssystem öffnen kannst.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Diese eine Datei enthält deine Tabellen, deine Indizes, dein Schema und deine Daten. SQLite-Datenbanken sind auf der Festplatte Byte für Byte identisch – egal ob unter Windows, macOS, Linux, iOS oder Android. Das Format ist so stabil, dass die US-amerikanische Library of Congress es sogar für die langfristige Datenarchivierung empfiehlt.

Wo du SQLite längst benutzt

Auf dem Gerät, auf dem du das hier gerade liest, liegen mit ziemlicher Sicherheit hunderte SQLite-Datenbanken. SQLite steckt in:

• iOS und Android – im System selbst und in vielen Apps auf beiden Plattformen.
• Firefox, Chrome und Safari (Verlauf, Lesezeichen, Cookies).
• macOS (Mail, Fotos, das Dock).
• Den meisten Linux-Desktop-Anwendungen, die lokal Daten ablegen müssen.
• Skype, WhatsApp, Signal – für den Chatverlauf.
• Adobe-Lightroom-Katalogen, Dropbox-Metadaten, Steam-Bibliotheken.

SQLite gilt als die am weitesten verbreitete Datenbank-Engine der Welt, und das stimmt vermutlich auch. Der Grund ist simpel: Sobald eine Anwendung strukturierten lokalen Speicher braucht, ist SQLite der Weg des geringsten Widerstands.

Was SQLite nicht ist

SQLite ist keine Client-Server-Datenbank. Zwei Programme auf unterschiedlichen Rechnern können sich nicht gemeinsam übers Netzwerk mit einer SQLite-Datenbank verbinden – es gibt schlicht keine Netzwerkschicht, an die man sich hängen könnte. Wer so etwas braucht, greift zu Postgres oder MySQL.

SQLite ist auch nicht für hohe Schreib-Parallelität gebaut. Es arbeitet mit Locks auf Dateiebene (mit ein paar cleveren Optimierungen im WAL-Modus). Das heißt: Viele Leser können gleichzeitig zugreifen, aber nur ein einziger Writer darf zur selben Zeit committen. Für eine Single-User-App oder eine Website mit wenig Traffic ist das völlig egal. Für ein mehrmandantenfähiges SaaS mit tausenden Schreibvorgängen pro Sekunde ist es das falsche Werkzeug.

SQLite verwaltet keine Nutzer und keine Berechtigungen. Datenbankzugriff ist hier gleichbedeutend mit Dateizugriff – wer die Datei lesen kann, sieht auch die Daten. Für eine App, der ihre eigene Datenbankdatei gehört, ist das in Ordnung. Für ein gemeinsam genutztes Multi-Tenant-Setup eher nicht.

Wofür sich SQLite lohnt

Du tauschst Einfachheit gegen Skalierungsspielraum, den du wahrscheinlich nie brauchen wirst:

• Null Setup. Kein Dienst, der laufen muss. Keine Versionskonflikte zwischen Dev und Prod. Kein "die Datenbank ist down", weil es schlicht keinen Datenbankserver gibt.
• Schnell. Bei den meisten Workloads – besonders bei leselastigen – ist SQLite schneller als eine Netzwerkdatenbank. Es gibt keinen Socket-Roundtrip pro Query.
• Zuverlässig. SQLite wird geradezu manisch getestet. Das Projekt hat um ein Vielfaches mehr Testcode als eigentlichen Quellcode, und das Dateiformat ist seit 2004 stabil.
• Public Domain. Kostenlos für jeden Einsatz, auch kommerziell. Keine Lizenz, in der man sich verlieren könnte.
• Portabel. Eine Datei, jede Plattform.

Für lokale Anwendungen, Prototypen, Embedded-Geräte, CLI-Tools, Test-Suites, Datenanalyse-Skripte sowie kleine bis mittelgroße Websites ist SQLite oft der richtige Default – und keine Notlösung, von der man später auf eine "richtige" Datenbank umsteigen muss.

Als Nächstes: SQLite vs MySQL

Die nächste naheliegende Frage: Wie schlägt sich SQLite eigentlich gegen die Datenbankserver, von denen du wahrscheinlich öfter gehört hast? Wir fangen mit MySQL an – wo jede der beiden punktet und wie du erkennst, welche zu deinem aktuellen Projekt passt.