SQLite in Produktion: Was Julia Evans gelernt hat, als sie es wirklich laufen ließ

Julia Evans veröffentlicht ihre Notizen zu SQLite: nichts Spektakuläres, alles sehr nützlich für diejenigen, die zögern, eine echte Anwendung auf dieser kleinen Datei laufen zu lassen.

Der konkrete Fall

Julia Evans - deren Zines und Artikel eine Generation von Entwicklern über die Internals von Linux, HTTP, DNS aufgeklärt haben - veröffentlichte am 17. Juli 2026 auf ihrem Blog jvns.ca einen Beitrag mit dem Titel « Learning a few things about running SQLite ». Es ist weder ein Einführungstutorial noch eine religiöse Predigt: Es ist ein Feldbericht einer Person, die SQLite in ihrer eigenen Anwendung in Produktion gesetzt hat und notiert, was sie überrascht hat. Ein Genuss.

Was man daraus lernt

Wir werden den Artikel nicht spoilern - gehen Sie hin und lesen Sie ihn, er ist auf Englisch, aber kurz -, aber einige Punkte tauchen regelmäßig in den Debatten über SQLite in der Produktion auf und verdienen es, hier für die Neugierigen erinnert zu werden:

1. WAL-Modus: Unverzichtbar für die Konkurrenz

Standardmäßig verwendet SQLite den Journalmodus DELETE, bei dem Schreibvorgänge Lesevorgänge blockieren. Im WAL (Write-Ahead Logging)-Modus blockieren Lesevorgänge Schreibvorgänge nicht mehr und umgekehrt:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL (anstatt FULL) akzeptiert, dass im Falle eines plötzlichen Stromausfalls maximal die letzte Transaktion verloren geht, im Austausch für eine massive Leistungssteigerung. Dies ist das, was Litestream und die meisten modernen SQLite-Server tun.

2. Ein einzelner Schreibverbindung, mehrere Leseverbindungen

Im Gegensatz zu PostgreSQL parallelisiert SQLite nicht die Schreibvorgänge. Ein klassisches Muster in Rust oder Go: eine einzige Verbindung, die dem Schreiben vorbehalten ist, ein Pool von Verbindungen für das Lesen. Dies ist das Modell der Crate rusqlite in Kombination mit deadpool-sqlite mit dieser Trennung oder der Go-Bibliothek mattn/go-sqlite3 mit sql.DB konfiguriert SetMaxOpenConns(1) für das Schreiben.

3. Live-Backups: Litestream oder LiteFS

Eine SQLite-Datei "per Kopie" zu sichern, während eine Transaktion läuft, ist die beste Methode, um ein beschädigtes Backup zu erhalten. Zwei Tools dominieren:

• Litestream (von Ben Johnson, auch Autor von BoltDB): kontinuierliche Replikation an S3, Backblaze B2 oder GCS. Streaming des WAL, schnelle Wiederherstellung.
• LiteFS (derselbe Autor, jetzt bei Fly.io): geht weiter, Replikation auf mehreren Knoten mit Lesen von jeder Replikation.

4. Die echte Grenze von SQLite im Jahr 2026

SQLite hält problemlos Dutzende von tausend Anfragen pro Sekunde auf einer einzigen Datei aus, vorausgesetzt, es wird im WAL-Modus und gut indexiert. Die echte Grenze ist nicht SQL, sondern die Festplatte: lokales NVMe >> Netzwerkfestplatte, EBS gp3 >> EFS. Viele SQLite-Fehler in der Produktion kommen daher, dass die Datei auf einem Netzwerk-Share (NFS insbesondere - SQLite rät explizit in Fett in seiner Dokumentation sqlite.org/faq.html#q5 davon ab) abgelegt wurde.

Zu beachten

Julia Evans' Standpunkt, wie immer, ist: ausprobieren, messen, aufschreiben, was man findet. Kein "SQLite scales" oder "you need Postgres for anything real". Einfach: dieses Verhalten hat mich überrascht, deshalb, deshalb habe ich es geändert.

Für jeden Entwickler, der zögert, die große relationale Artillerie für eine Single-Server-Anwendung oder ein Side-Projekt einzusetzen, sind Artikel dieser Art hundert synthetische Benchmarks wert.