SQLite: die Einzeldatei-Datenbank für Single-Tenant, Mobile und Edge

Was ist SQLite?

SQLite ist eine embedded relationale Datenbank: keine separate Server-Komponente, kein Netzwerk-Protokoll, kein Daemon. Die gesamte DB lebt als eine einzige Datei auf der Festplatte, und die Anwendung greift über eine in C geschriebene Library direkt darauf zu. Public Domain (technisch CC0), entwickelt seit 2000 von D. Richard Hipp und einem kleinen Team in den USA, mit der erklärten Mission, ein Jahrhundert-stabiles Datenformat zu liefern.

SQLite ist die am häufigsten deployed Datenbank der Welt -- auf jedem Android- und iOS-Smartphone, in jedem Firefox- und Chrome-Browser, in jedem Mac- und Windows-Computer, in fast jedem Embedded-Gerät. Im Mai 2026 ist Version 3.46 stabil. Das Dateiformat wird offiziell bis 2050 als kompatibel garantiert -- diese Langlebigkeit-Garantie ist im Datenbank-Markt einzigartig.

Funktional ist SQLite SQL-92-konform mit modernen Erweiterungen: Window-Functions, CTEs, JSON-Operatoren, Full-Text-Search (FTS5), R-Tree-Index für Geo-Daten, sqlite-vec für Vector-Search (seit 2024). Was SQLite nicht hat: User/Permission-Management (eine SQLite-Datei hat einen Eigentümer auf OS-Ebene), Concurrent-Writers (es schreibt immer nur ein Prozess gleichzeitig in eine Datei), serverbasierte Replikation. Concurrent-Reader sind unbegrenzt -- WAL-Mode macht Reads parallel zu Writes möglich.

In unserem Stack läuft SQLite produktiv bei Fairlane (Legal-Case-Management mit 60+ Tabellen, 696 Schweizer Gesetze als FTS-Index) und Realty51 (Immobilien-Portal mit 60+ Tabellen, 300+ Properties). Beide Anwendungen sind Single-Tenant aus Sicht der Datei -- ein Server, eine Anwendung, eine DB-Datei. Backup via Litestream in S3-kompatiblen Speicher, mit Live-WAL-Replikation und RPO unter 1 Sekunde.

Warum es wichtig ist

SQLite wird in der KMU-Welt oft unterschätzt -- als "nur Test-DB" oder "für kleine Apps". Das ist 2026 falsch. Drei Gründe, warum SQLite eine erstrangige Produktiv-Option ist.

Erstens: Operations-Aufwand gegen Null. Keine separate DB-Installation, keine Connection-Pools, keine Replikations-Konfiguration, kein Backup-Daemon. Die DB ist eine Datei, die mit der Anwendung lebt. Ein Anwendungs-Restart umgeht jeglichen DB-Daemon-Crash. Ein Backup ist ein cp-Befehl auf der Datei (im WAL-Mode mit sqlite3 .backup-Kommando). Für ein KMU mit 1-2 IT-Personen ist das ein echter Vorteil -- weniger Operations-Last, weniger Failure-Modes.

Zweitens: Geschwindigkeit. SQLite-Reads gehen direkt durch den OS-Page-Cache, ohne IPC-Overhead. Ein SELECT über 100k Zeilen mit Index ist typisch in 1-5 ms zurück. Schreib-Operationen via INSERT/UPDATE in Transaktion-Bundles erreichen 50k-100k Operationen pro Sekunde auf NVMe-SSD. Für 99 Prozent der KMU-Workloads ist das ueppig schnell.

Drittens: Datei-Portabilität. Eine SQLite-DB kann zwischen Servern via scp kopiert werden. Eine Anwendung kann gleichzeitig lokal entwickelt (mit lokaler DB-Datei) und produktiv gefahren werden (mit Server-DB-Datei) -- ohne Konfigurations-Aufwand. Migration zwischen Hosting-Providern ist einfach. Disaster-Recovery ist einfach: Datei zurückkopieren, Anwendung starten.

Für welche Fälle ist SQLite NICHT geeignet? Multi-Tenant-SaaS mit hoher Concurrent-Write-Last (z.B. ein System mit 100+ gleichzeitigen Schreibern), Multi-Server-Deployments mit horizontaler Lastverteilung, Anwendungen mit 24/7-zwingender Sub-Sekunden-Failover-Anforderung. In diesen Fällen gehört man zu PostgreSQL oder einer verteilten DB.

Wie es funktioniert

Eine SQLite-Datenbank ist eine einzige Datei (default: .db oder .sqlite Endung). Die Anwendung öffnet diese Datei via libsqlite3 und schreibt SQL-Befehle direkt -- keine Netzwerk-Verbindung, kein TCP-Stack. Treiber für alle gängigen Sprachen: better-sqlite3 (Node, synchron, schnell), sqlite3 (Python Standard-Library), Microsoft.Data.Sqlite (.NET), rusqlite (Rust).

Das wichtigste Konfigurations-Detail ist der Journal-Mode. Default ist DELETE (rollback-Journal), aber für fast jeden produktiven Einsatz schaltet man auf WAL (Write-Ahead-Log) um:

PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA temp_store=MEMORY; PRAGMA mmap_size=30000000000; PRAGMA foreign_keys=ON;

WAL-Mode erlaubt Concurrent-Reads parallel zu Writes -- der Schreiber blockiert die Leser nicht. mmap_size mappt die DB-Datei in den Speicher, was Reads deutlich beschleunigt. synchronous=NORMAL ist ein guter Kompromiss zwischen Durability und Geschwindigkeit; FULL ist sicherer, aber langsamer.

Ein Schema-Beispiel mit FTS5 (Full-Text-Search) und sqlite-vec (Vector-Search):

CREATE TABLE fälle ( id INTEGER PRIMARY KEY AUTOINCREMENT, titel TEXT NOT NULL, inhalt TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP );

CREATE VIRTUAL TABLE fälle_fts USING fts5(titel, inhalt, content='fälle', content_rowid='id');

CREATE VIRTUAL TABLE fälle_vec USING vec0(embedding float[1536]);

FTS5 ist der eingebaute Full-Text-Index, sqlite-vec ist eine separate Extension für Embeddings. Beide laufen in der gleichen DB-Datei.

Für Live-Replikation und Cloud-Backup ist Litestream das Standard-Tool. Es läuft als Sidecar-Prozess neben der Anwendung, beobachtet das WAL-File und repliziert Änderungen kontinuierlich nach S3, MinIO, GCS oder Azure Blob. RPO unter 1 Sekunde, Restore via litestream restore -o app.db s3://bucket/app.db. Bei Disaster-Recovery: neuer Server, Litestream-Restore, Anwendung starten -- typisch 5-15 Minuten.

Limits: SQLite-Dateien skalieren technisch bis 281 TB, praktisch komfortabel bis 100-500 GB. Schreib-Concurrency ist auf eine Transaktion pro Zeit limitiert. Concurrent-Reader sind unbegrenzt. Wer mehr Concurrent-Writes braucht, betrachtet rqlite (Raft-basierter SQLite-Cluster) oder LiteFS (Fly.io-Tool für SQLite-Replikation).

SQLite in 5 Schritten produktiv

1. 01Anwendung mit SQLite-Treiber bauen (better-sqlite3, sqlite3, etc), DB-Datei in einem persistenten Verzeichnis ablegen.
2. 02PRAGMAs setzen: journal_mode=WAL, synchronous=NORMAL, mmap_size auf RAM-Grösse, foreign_keys=ON. Indexes auf allen Filter-Spalten anlegen.
3. 03Litestream installieren und konfigurieren: Replikation in S3-kompatiblen Speicher (Hetzner Storage Box, Wasabi EU, MinIO), Sync-Interval 1 Sekunde.
4. 04Backup-Verifikation einrichten: wöchentlicher Litestream-Restore in Staging-Umgebung, Daten-Konsistenz-Check via Sample-Queries.
5. 05Monitoring anbinden: Application-Level-Metriken via Prometheus (Query-Latenz, Transaktions-Rate), Disk-Space-Alert bei > 80 Prozent.

Wann SQLite einsetzen

Die richtige Wahl, wenn (a) eine Anwendung Single-Tenant ist (ein Server, eine Anwendung, eine DB), (b) Concurrent-Writes unter 50 pro Sekunde bleiben, oder (c) der Aufwand für einen separaten DB-Server-Stack vermieden werden soll.

Konkrete Szenarien: ein Anwalts-Case-Management für eine Kanzlei mit 5-50 Anwälten (Fairlane), eine Immobilien-Portal-App für einen lokalen Anbieter (Realty51), eine Treuhand-Eigenentwicklung für ein Büro, eine Desktop-Anwendung wie Buchhaltungssoftware oder Mandanten-Verwaltung, eine eingebettete Anwendung auf Raspberry Pi / Industrie-PC, eine mobile App mit Offline-Sync (iOS/Android).

Auch interessant: schreibe-arme High-Read-Workloads. SQLite mit WAL-Mode und mmap_size handhabt einfach 1000+ Reads pro Sekunde aus einer Datei. Wikipedia-style Read-Mostly-Wikis, statische Inhalte mit dynamischer Suche, Knowledge-Bases. Wenn 95 Prozent der Anfragen Reads sind, ist die Concurrent-Write-Limitation kein Problem.

Edge-Computing: SQLite läuft auf Cloudflare Workers (via D1), Fly.io (mit LiteFS), Turso (verteilte SQLite-Datenbanken), AWS Lambda. Für Edge-Workloads mit Read-Mostly-Last ist SQLite die optimal verteilte DB -- die Datei wird auf den Edge-Knoten kopiert, Reads sind lokal, Writes gehen zu einem zentralen Knoten.

Wann NICHT

Multi-Tenant-SaaS mit hoher Concurrent-Write-Last: wenn 100 oder mehr Anwender gleichzeitig schreiben (z.B. ein CRM mit 200 Vertriebsmitarbeitern in Echtzeit), wird die Single-Writer-Limitation zum Engpass. PostgreSQL ist hier richtig.

Multi-Server-Deployments mit horizontaler Lastverteilung: wenn die Anwendung auf mehreren App-Servern hinter einem Load-Balancer läuft, wird die SQLite-Datei zum Single-Point-of-Failure. Man könnte mit LiteFS oder rqlite distribuieren, aber das ist operativ aufwendiger als ein klassisches Postgres-Setup.

Reports und Analytics mit komplexen Aggregaten über zig Millionen Zeilen: SQLite ist nicht columnar, Aggregat-Performance ist OK aber nicht herausragend. Für Reporting auf 100M+ Zeilen ist DuckDB (auch embedded!) deutlich schneller -- oft 50-100x bei reinen Analyse-Workloads.

24/7-zwingende Sub-Sekunden-Failover: SQLite ist kein hochverfügbares System. Bei einem Datei-Crash dauert Restore Minuten, nicht Millisekunden. Wer SLA mit RTO unter 1 Min braucht, gehört auf Postgres mit Standby-Replikation oder CockroachDB.

Grosse Backups übers Netzwerk: eine 100-GB-SQLite-Datei zu kopieren dauert je nach Netzwerk 10-60 Minuten. Mit Litestream ist inkrementelle Replikation möglich, aber Initial-Restore bleibt langsam. Bei wirklich grossen DBs (> 500 GB) ist Postgres mit pg_basebackup besser.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. SQLite official documentation · 2026-05
2. SQLite long-term file format guarantee · 2026-05
3. Litestream documentation -- live SQLite replication · 2026-04
4. sqlite-vec extension GitHub releases · 2026-05