Wann SQLite sinnvoll ist – und wann nicht

Die zentrale Frage

SQLite ist keine abgespeckte Postgres-Variante. Es ist ein Werkzeug mit einer ganz anderen Form. Die komplette Datenbank ist eine Datei auf der Festplatte, und deine Anwendung spricht über eine Bibliothek mit ihr, die direkt in denselben Prozess eingebunden ist — kein Server, kein Netzwerk, keine Benutzerverwaltung. Genau dieser Aufbau macht SQLite für manche Aufgaben unschlagbar und für andere ziemlich ungeeignet.

Die entscheidende Frage lautet fast nie „Ist SQLite schnell genug?" (das ist es meistens). Sondern: „Passt die Form meiner Anwendung zu dem, worin SQLite stark ist?" Zwei Dinge bestimmen das im Wesentlichen: wo die Daten liegen — und wie viele Stellen gleichzeitig darauf schreiben.

Wann SQLite verwenden: wenn die Daten bei der App liegen

SQLite spielt seine Stärken aus, wenn die Datenbank zu genau einer Anwendung auf genau einer Maschine gehört. Die Datei liegt direkt neben deinem Code, die App öffnet sie unmittelbar — und das ist schon die ganze Architektur.

-- Ein typisches Schema nach dem Motto "Daten leben mit der App":
-- der lokale Speicher einer Desktop-Notiz-App.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Einkäufe', 'Milch, Brot, Kaffee'),
    ('Ideen',    'Gliederung SQLite-Tutorial');

SELECT id, title, created FROM notes;

Dieses winzige Schema kann durchaus das komplette Backend einer echten Anwendung sein. Ein paar typische SQLite Anwendungsfälle, in denen dieses Muster wie selbstverständlich passt:

• Desktop- und Mobile-Apps. Jede iOS- und Android-App, die strukturierte lokale Daten ablegen muss, nutzt unter der Haube SQLite. Genauso Firefox, Chrome und die meisten anderen Browser.
• CLI-Tools. git, Paketmanager und Dotfile-Manager setzen alle auf eine embedded Datenbank.
• Embedded-Geräte. Router, Autos, Flugzeuge — überall dort, wo eine Datenbank nur ein paar hundert Kilobyte groß sein darf.
• Testsuites. Eine frische SQLite-Datei (oder eine :memory:-Datenbank) pro Test ist schneller und sauberer isoliert, als für jeden Lauf einen Postgres hochzufahren.

Solange deine Daten nicht über mehrere Maschinen hinweg geteilt werden müssen, ist SQLite meistens die richtige Wahl.

SQLite für Webanwendungen mit vielen Lesezugriffen

Beim Lesen spielt SQLite seine Stärken voll aus. Viele parallele Reader, keine Sperrkonflikte, Abfragezeiten im Mikrosekundenbereich bei indexierten Lookups. Wenn auf deiner Seite hauptsächlich Inhalte gelesen werden — Blogs, Dokumentationen, Marketing-Sites, kleinere SaaS-Dashboards — kommt SQLite locker mit. Oft sogar besser als ein Postgres über Netzwerk, einfach weil der Round-Trip wegfällt.

-- Die Posts-Tabelle eines Blogs.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Hallo, Welt', 'Erster Beitrag.', '2024-01-01'),
    ('sqlite-rocks', 'Warum SQLite',  'Datenbank in einer einzigen Datei.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

Der Haken sind die Schreibzugriffe. SQLite serialisiert Schreibvorgänge — es kann immer nur ein Writer gleichzeitig den Lock halten. Bei einem Blog mit ein paar Autoren merkt man das überhaupt nicht. Bei einer Chat-App, in der Tausende User pro Sekunde Nachrichten posten, wird daraus aber schnell ein Engpass.

Der WAL-Modus (Write-Ahead Logging, dazu später mehr) hebt die Grenze für die SQLite-Nebenläufigkeit deutlich an, weil Leser und der Writer dann parallel arbeiten können. Es gibt jede Menge produktiv eingesetzter SQLite-Setups, die mit WAL Millionen Requests pro Tag bedienen.

SQLite als lokaler Cache und für Zwischendaten

Sobald du strukturierten lokalen Speicher brauchst — mehr als eine JSON-Datei, aber weniger als einen ausgewachsenen Datenbankserver — ist SQLite als embedded Datenbank kaum zu schlagen.

-- Eine Cache-Tabelle für einen HTTP-Client.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Logs, Analytics-Puffer, ETL-Staging, Feature-Stores fürs Machine Learning, IDE-Indizes – das alles sind klassische Einsatzgebiete für SQLite. Die Datei ist portabel, als Abfragesprache hast du vollwertiges SQL, und einen Server musst du auch nicht betreuen.

SQLite Grenzen: viele parallele Schreibzugriffe

Genau hier stolpern die meisten. SQLite arbeitet mit einem Write-Lock auf Datenbankebene: ein einziger Writer, mehr geht nicht. Wollen zwei Prozesse gleichzeitig schreiben, muss einer warten.

Für die meisten Anwendungen ist das völlig egal – geschrieben wird ohnehin selten und kurz. Sieht dein Workload aber so aus:

• ein mandantenfähiges SaaS, bei dem Tausende Nutzer gleichzeitig schreiben,
• eine Message Queue oder ein Event-Log mit hohem Durchsatz,
• ein Echtzeit-Game- oder Chat-Backend mit ständigen Zustandsänderungen,

dann wird SQLite zum Flaschenhals. Postgres und MySQL setzen auf Row-Level-Locking und wurden genau für solche Szenarien gebaut. In dem Fall: lieber dorthin greifen.

-- Der Fehler, den du siehst, wenn sich Schreibvorgänge stauen:
Error: database is locked

Wenn du das unter normaler Last beobachtest, ist SQLite schlicht das falsche Werkzeug – kein Bug, den man umgehen müsste.

SQLite nicht über mehrere Maschinen hinweg einsetzen

SQLite ist eine In-Process-Bibliothek: Die Anwendung liest und schreibt direkt in die Datei. Das heißt, die Datei muss auf einem Datenträger liegen, auf den die Anwendung mit ganz normalen Dateisystem-Aufrufen per read() und write() zugreifen kann.

Damit fallen folgende Szenarien raus:

• Mehrere Application-Server hinter einem Load Balancer, die sich eine gemeinsame Datenbank teilen sollen. (Netzwerk-Dateisysteme wie NFS funktionieren technisch, korrumpieren die Datei aber unter Last. Lass es.)
• Serverless-Funktionen, bei denen jeder Aufruf auf einer anderen Maschine läuft.
• Kubernetes-Pods, die eine gemeinsame Datenbank brauchen – außer du fährst ein Single-Pod-Deployment mit Persistent Volume.

Sobald deine Architektur mehrere Prozesse auf mehreren Maschinen hat, die schreibend auf die Datenbank zugreifen, brauchst du eine Client-Server-Datenbank. Da verläuft die Grenze.

Kein SQLite, wenn du Benutzer auf Datenbankebene brauchst

SQLite kennt keine User, keine Rollen, keine Berechtigungen. Die Datenbank ist eine Datei – wer die Datei lesen kann, liest alles; wer sie schreiben kann, schreibt alles. Die Zugriffskontrolle übernimmt das Betriebssystem.

Für eine Single-User-Desktop-App ist das völlig in Ordnung. Sobald du aber ein mandantenfähiges System baust, in dem verschiedene Personen innerhalb der Datenbank unterschiedliche Rechte brauchen, willst du Postgres oder MySQL.

Kurze Entscheidungs-Checkliste: wann SQLite verwenden

Geh die Liste einmal durch. Wenn du überall mit „ja" antwortest, ist SQLite vermutlich die richtige Wahl:

• Die Datenbank liegt auf derselben Maschine wie die Anwendung.
• Genau ein Prozess (oder eine Handvoll, überwiegend lesend) greift darauf zu.
• Die gesamten Daten passen bequem auf einen Datenträger – Terabytes sind okay, aber es bleibt eine einzelne Platte.
• Du brauchst keine Benutzerrechte auf Datenbankebene.
• Gleichzeitige Schreibzugriffe sind die Ausnahme, nicht der Hauptanwendungsfall.

Sobald irgendwo ein „nein" steht, schau dir lieber Postgres oder MySQL an. Die nächsten beiden Seiten vergleichen beide direkt – Stichwort SQLite vs PostgreSQL und SQLite vs MySQL.

Das Wichtigste auf einen Blick

• SQLite ist die richtige Wahl, wenn die Datenbank lokal zur Anwendung läuft: Desktop, Mobile, Embedded, CLI-Tools, Testsuites, leselastige Websites, lokale Caches.
• Es ist produktionsreif – Milliarden Geräte liefern SQLite mit. Die Einschränkungen sind architektonischer Natur, nicht Qualitätsfragen.
• Lass die Finger davon, wenn du viele parallele Writer, Zugriff von mehreren Maschinen oder Datenbank-Berechtigungen pro Nutzer brauchst.

Als Nächstes: SQLite installieren

Genug Theorie. Auf der nächsten Seite installieren wir SQLite auf deinem Rechner – auf macOS und den meisten Linux-Distributionen ist es schon dabei, unter Windows reicht ein Download – und prüfen die Installation anschließend auf der Kommandozeile.