SQLite wird unterschätzt, da die Leute es mit Prototypen und lokalen Werkzeugen assoziieren.
Das ist ein Fehler.
Es ist eine ernsthafte Datenbank mit einer starken Zuverlässigkeitsgeschichte und einem extrem einfachen Betriebsmodell.
Der Schlüssel ist zu verstehen, bei welcher Art von Arbeitslast es gut ist.
Warum SQLite Schnell Wirkt
Der offensichtliche Vorteil ist die Lokalität.
Es gibt keinen separaten Datenbankserver, keinen Netzwerk-Hops und keinen Verbindungspool zwischen der Anwendung und der Datendatei. Bei leselastigen lokalen Arbeitslasten kann diese Einfachheit sehr effektiv sein.
Wo Es Gut Passt
SQLite ist oft eine starke Option für:
- eingebettete Anwendungen
- Edge- oder Einzelknotenbereitstellungen
- interne Werkzeuge
- leselastige Arbeitslasten mit bescheidener Schreibkonkurrenz
Das ist ein bedeutender Satz von Systemen.
Wo Es Weniger Gut Passt
Sie sollten vorsichtiger sein, wenn Sie benötigen:
- hohe Schreibkonkurrenz von vielen Prozessen
- Multi-Knoten-Schreibkoordination
- komplexe operationale Replikationsbedarfe direkt ab Werk
- intensive analytische Arbeitslasten über viele Anwendungsnoten hinweg
Hier ist PostgreSQL oder eine andere Client-Server-Datenbank in der Regel die bessere Wahl.
WAL-Modus Zählt
Wenn Sie SQLite in der Produktion verwenden, verstehen Sie das Write-Ahead Logging:
- es verbessert das Konkurrenzverhalten
- es erlaubt Lesern und Schreibern, besser zusammenzuleben
- es ändert, wie die Datenbankdatei operationell verwaltet wird
Das ist ein Grund, warum SQLite in realen Systemen viel besser funktioniert, als viele Ingenieure annehmen.
Die Ehrliche Zusammenfassung
SQLite ist kein Spielzeug.
PostgreSQL ist nicht übertrieben.
Die richtige Wahl hängt davon ab, ob Ihr System mehr von:
- lokaler Einfachheit und niedrigem operationellen Aufwand
oder
- Client-Server-Konkurrenz und einer umfangreicheren Datenbankinfrastruktur
profitiert.
Das ist die tatsächliche Entscheidung.
Weitere Literatur