SQLite vs MySQL: Architektur, Performance und wann jedes davon wirklich relevant ist

Die Wahl zwischen SQLite und MySQL ist nicht bloß eine Frage der Präferenz – es ist eine architektonische Entscheidung mit langfristigen Konsequenzen für Skalierbarkeit, Nebenläufigkeit, Datenintegrität und Betriebsaufwand. SQLite ist eine serverlose, eingebettete Datenbank-Engine, die als einzelne Datei auf dem Datenträger gespeichert wird, keine Konfiguration erfordert und keinen separaten Prozess benötigt. MySQL ist ein vollständiges Client-Server-Relationales-Datenbankmanagementsystem (RDBMS), das für Mehrbenutzerumgebungen, gleichzeitige Schreibworkloads und unternehmensweite Deployments konzipiert ist. Zu verstehen, wo jedes System glänzt – und wo es an seine Grenzen stößt – verhindert kostspielige Neuarchitekturierungen in der Zukunft.

Beide Systeme sind ACID-konform und sprechen SQL, aber ihre internen Mechanismen, Sperrmodelle, Replikationsfähigkeiten und Sicherheitsoberflächen sind grundlegend verschieden. Dieser Leitfaden analysiert jede relevante Dimension, damit Sie eine fundierte, technisch begründete Entscheidung treffen können.

Was ist SQLite?

SQLite ist eine quelloffene, eigenständige, serverlose SQL-Datenbank-Engine, die von D. Richard Hipp gepflegt und in die Public Domain veröffentlicht wurde. Die gesamte Datenbank – Schema, Tabellen, Indizes und Daten – befindet sich in einer einzelnen plattformübergreifenden .db-Datei auf dem Datenträger. Es gibt keinen Daemon zu starten, keinen Port zu öffnen und keine Authentifizierungsschicht zu konfigurieren. Die SQLite-Bibliothek wird direkt in die Anwendungsbinärdatei eingebunden, wodurch die Datenbank-Engine ein integraler Bestandteil des Prozesses selbst wird.

Diese Architektur macht SQLite zur weltweit am häufigsten eingesetzten Datenbank-Engine gemessen an der reinen Instanzanzahl. Sie ist in jedem Android- und iOS-Gerät, jedem Chrome- und Firefox-Browser, jeder macOS- und Windows-Installation sowie unzähligen eingebetteten Firmware-Images enthalten.

Wichtige technische Merkmale von SQLite

• Serverlose Ausführung: Der Anwendungsprozess liest und schreibt die .db-Datei direkt über Datei-I/O auf Betriebssystemebene und umgeht dabei jeden Netzwerk-Stack.
• Single-Writer-Modell: SQLite verwendet Sperren auf Datenbankebene. Nur ein Schreiber kann gleichzeitig die Schreibsperre halten; gleichzeitige Leser sind während einer Lesetransaktion erlaubt, werden jedoch während eines Schreibvorgangs blockiert.
• Dynamisches Typsystem (Typaffinität): Spaltentypen sind empfehlend, nicht erzwingend. Eine als INTEGER deklarierte Spalte speichert problemlos eine Textzeichenkette. Dies ist beabsichtigt, kann jedoch zu subtilen Datenintegritätsproblemen führen, wenn die Anwendungsschicht keine Typen erzwingt.
• WAL-Modus (Write-Ahead Logging): Die Aktivierung des WAL-Modus (PRAGMA journal_mode=WAL) verbessert die Lesenebenläufigkeit erheblich, indem Leser und ein einzelner Schreiber gleichzeitig arbeiten können, ohne sich gegenseitig zu blockieren.
• Maximale Datenbankgröße: Theoretisch bis zu 281 TB, obwohl praktische Grenzen durch das Dateisystem und die Leistungsverschlechterung bei großem Maßstab gesetzt werden.
• Zero-Copy-Deployment: Das Verteilen oder Sichern einer SQLite-Datenbank ist so einfach wie das Kopieren einer einzelnen Datei.

Wo SQLite das richtige Werkzeug ist

• Mobile Anwendungen (iOS, Android): Beide Plattformen bieten native SQLite-Bindungen. Das Fehlen eines Netzwerk-Round-Trips bedeutet Sub-Millisekunden-Abfragelatenz für lokale Daten.
• Eingebettete Geräte und IoT: Eingeschränkte Umgebungen mit begrenztem RAM und ohne Netzwerkkonnektivität sind ideal für SQLite.
• Desktop-Anwendungen: Electron-Apps, lokale Analyse-Tools und offline-fähige Software profitieren von SQLites Zero-Configuration-Modell.
• Browser-seitiger Speicher: Die Web SQL API (inzwischen veraltet) basierte auf SQLite; moderne Alternativen wie wa-sqlite bringen sie zu WebAssembly.
• Automatisiertes Testen und CI-Pipelines: Das Ersetzen einer produktiven MySQL-Datenbank durch eine In-Memory-SQLite-Instanz (:memory:) während Unit-Tests eliminiert externe Abhängigkeiten und beschleunigt Test-Suites erheblich.
• Konfigurations- und Cache-Speicher: Anwendungen, die strukturierte lokale Persistenz ohne den Overhead eines vollständigen RDBMS benötigen – etwa Anwendungseinstellungen, lokale Caches oder Offline-Warteschlangen – sind natürliche SQLite-Nutzer.

Was ist MySQL?

MySQL ist ein vollständiges Client-Server-RDBMS, das ursprünglich von MySQL AB entwickelt wurde und nun von Oracle Corporation unter einer dualen GPL/kommerziellen Lizenz gepflegt wird. Anwendungen kommunizieren mit dem MySQL-Server (mysqld) über TCP/IP oder einen Unix-Socket unter Verwendung des MySQL-Wire-Protokolls. Der Server verwaltet Connection-Pooling, Query-Parsing, Query-Optimierung, Transaktionsverwaltung und Storage-Engine-Dispatch unabhängig von einem einzelnen Client.

MySQLs pluggable Storage-Engine-Architektur ist eine seiner wichtigsten Designentscheidungen. InnoDB (Standard seit MySQL 5.5) bietet vollständige ACID-Konformität, Sperren auf Zeilenebene, Fremdschlüsselerzwingung und MVCC (Multi-Version Concurrency Control). MyISAM, die Legacy-Engine, bietet schnellere Lesevorgänge für bestimmte Workloads, verfügt jedoch nicht über Transaktionen und Sperren auf Zeilenebene – sie sollte für neue Projekte als veraltet betrachtet werden.

Wichtige technische Merkmale von MySQL

• MVCC-Nebenläufigkeitsmodell: InnoDB verwendet MVCC, um mehreren Transaktionen das Lesen konsistenter Datensnapshots zu ermöglichen, ohne Schreiber zu blockieren, und umgekehrt. Dies ist der Kernmechanismus, der hochdurchsatzfähige gleichzeitige Workloads ermöglicht.
• Sperren auf Zeilenebene: Konflikte sind auf einzelne Zeilen beschränkt und nicht auf die gesamte Tabelle oder Datenbank, was eine weitaus größere Schreibnebenläufigkeit als SQLites Sperre auf Datenbankebene ermöglicht.
• Strikte Typerzwingung: Spaltentypen werden auf Speicherebene erzwungen. Das Einfügen einer Zeichenkette in eine INT-Spalte löst einen Fehler aus (im strikten SQL-Modus) und schützt die Datenintegrität auf Datenbankebene.
• Replikation: MySQL unterstützt asynchrone und semi-synchrone Binary-Log (Binlog)-Replikation, Group Replication (Multi-Primary) und InnoDB Cluster für Hochverfügbarkeit.
• Stored Procedures, Trigger und Views: MySQL unterstützt serverseitige programmierbare Logik, die es ermöglicht, komplexe Geschäftsregeln auf Datenbankebene durchzusetzen.
• Volltextsuche: InnoDB-Volltextindizes unterstützen nativ Abfragen im Natural-Language- und Boolean-Modus.
• Benutzerverwaltung und RBAC: Granulare GRANT/REVOKE-Berechtigungen auf Datenbank-, Tabellen-, Spalten- und Routine-Ebene, kombiniert mit SSL/TLS-Client-Authentifizierung.

Wo MySQL das richtige Werkzeug ist

• Webanwendungen mit gleichzeitigen Benutzern: Jede Anwendung, bei der mehrere Benutzer gleichzeitig lesen und schreiben – WordPress, Magento, Laravel-Apps – erfordert MySQLs MVCC-Nebenläufigkeitsmodell.
• E-Commerce-Plattformen: Transaktionsintegrität, Fremdschlüssel-Constraints und Sperren auf Zeilenebene sind unverzichtbar, wenn es um Geld und Inventar geht.
• Multi-Tenant-SaaS-Produkte: Benutzerisolierung, rollenbasierte Zugriffskontrolle und die Möglichkeit zur horizontalen Skalierung über Read-Replicas sind auf SaaS-Ebene unerlässlich.
• Data Warehousing und Analytics: Während dedizierte OLAP-Systeme (ClickHouse, Redshift) MySQL bei analytischen Workloads übertreffen, bewältigt MySQL Reporting-Abfragen auf mittelgroßen Datensätzen (Hunderte von GB) effektiv.
• Hochverfügbare Produktionsumgebungen: InnoDB Cluster mit MySQL Router bietet automatisches Failover und macht MySQL zu einer geeigneten Wahl für Anwendungen mit strengen Uptime-SLAs.

Wenn Sie MySQL in einer Produktionsumgebung betreiben, ist die zugrunde liegende Infrastruktur genauso wichtig wie die Datenbankkonfiguration. Eine ordnungsgemäß abgestimmte VPS-Hosting-Umgebung mit dedizierter CPU- und RAM-Zuweisung verhindert die Ressourcenkonflikte, die die MySQL-Leistung unter Last beeinträchtigen.

Direkter Vergleich: SQLite vs MySQL

Architektur und Deployment

Nebenläufigkeit und Leistung

Datentypen und Integrität

Funktionen und Funktionalität

Sicherheit

Ein wichtiger Betriebshinweis: MySQLs Netzwerkexposition bedeutet, dass ein falsch konfiguriertes bind-address = 0.0.0.0 mit einem schwachen Root-Passwort ein häufiger Angriffsvektor ist. Binden Sie MySQL immer an 127.0.0.1 oder eine private Schnittstelle, erzwingen Sie SSL/TLS für Remote-Verbindungen und kombinieren Sie Ihren Datenbankserver mit einem gültigen SSL-Zertifikat für jede weborientierte Anwendungsschicht.

Benutzerfreundlichkeit und Betriebsaufwand

Leistungstiefenanalyse: Wo jede Engine tatsächlich gewinnt

SQLite-Leistungsstärken

SQLites Leistungsvorteil in Einzelbenutzer- oder Niedrig-Nebenläufigkeits-Szenarien ergibt sich aus der vollständigen Eliminierung des Netzwerk-Stacks. Eine lokale SQLite-Abfrage wird in Mikrosekunden ausgeführt; die äquivalente MySQL-Abfrage verursacht Socket-Overhead, Authentifizierungs-Handshake-Amortisierung und Query-Parsing auf dem Server – alles bevor die Storage-Engine ein einziges Byte berührt.

Für leselastige Einzelbenutzer-Workloads – eine mobile App, die einen lokalen Produktkatalog abfragt, ein Desktop-Tool, das Konfigurationsdaten liest, oder eine Test-Suite, die isolierte Datenbankoperationen ausführt – übertrifft SQLite MySQL bei der reinen Latenz konsistent.

Der WAL-Modus ist für jedes ernsthafte SQLite-Deployment nicht optional. Ohne WAL erwirbt jeder Schreibvorgang eine exklusive Sperre, die alle Leser blockiert. Mit aktiviertem WAL:

sqlite3 mydb.db "PRAGMA journal_mode=WAL;"

Leser und ein einzelner Schreiber können gleichzeitig arbeiten, und die Schreibleistung verbessert sich erheblich, da sequentielle Log-Schreibvorgänge zufällige Seitenüberschreibungen ersetzen.

MySQL-Leistungsstärken

MySQLs InnoDB-Engine ist für gleichzeitige, gemischte Lese-Schreib-Workloads konzipiert. Die MVCC-Implementierung bedeutet, dass ein lang laufendes SELECT keine INSERT– oder UPDATE-Operationen auf denselben Zeilen blockiert – jede Transaktion sieht einen konsistenten Snapshot der Daten zu ihrem Startzeitpunkt.

Kritische InnoDB-Tuning-Parameter, die jeder MySQL-Administrator kennen muss:

# /etc/mysql/mysql.conf.d/mysqld.cnf
innodb_buffer_pool_size = 70%_of_RAM   # Most important single parameter
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1     # Full ACID; set to 2 for performance at slight durability risk
innodb_flush_method = O_DIRECT
max_connections = 200                   # Tune based on workload; pair with connection pooling

Der Parameter innodb_buffer_pool_size allein macht den Großteil des MySQL-Performance-Tunings aus. Ihn auf 70–80 % des verfügbaren RAM auf einem dedizierten Datenbankserver einzustellen, reduziert die Festplatten-I/O erheblich, indem häufig genutzte Datenseiten im Speicher gehalten werden.

Für produktive MySQL-Deployments eliminiert ein Dedicated Server mit vorhersehbaren, nicht geteilten Ressourcen das Noisy-Neighbor-Problem, das die Effektivität von innodb_buffer_pool auf gemeinsam genutzter Infrastruktur beeinträchtigt.

Kritische Grenzfälle und häufige Fallstricke

SQLite-Fallstricke, die Entwickler überraschen

1. Die „funktioniert auf meinem Rechner”-Nebenläufigkeitsfalle. SQLites Single-Writer-Modell ist während der Entwicklung unsichtbar, wenn nur ein Entwickler in die Datenbank schreibt. In der Produktion erzeugt selbst moderate Nebenläufigkeit – zwei Hintergrundjobs, die gleichzeitig schreiben – SQLITE_BUSY-Fehler. Anwendungen müssen Wiederholungslogik mit exponentiellem Backoff implementieren:

import sqlite3
import time

def execute_with_retry(conn, query, params=(), retries=5, delay=0.1):
    for attempt in range(retries):
        try:
            conn.execute(query, params)
            conn.commit()
            return
        except sqlite3.OperationalError as e:
            if "database is locked" in str(e) and attempt < retries - 1:
                time.sleep(delay * (2 ** attempt))
            else:
                raise

2. Fremdschlüssel sind standardmäßig deaktiviert. Jede neue SQLite-Verbindung startet mit deaktivierter Fremdschlüsselerzwingung. Sie müssen sie explizit pro Verbindung aktivieren:

conn.execute("PRAGMA foreign_keys = ON")

Das Vergessen dieses Pragmas ist ein stiller Datenintegritätsfehler – verwaiste Zeilen häufen sich ohne Fehlermeldung an.

3. Typaffinitäts-Überraschungen. Das Einfügen von "2024-01-15" in eine als DATE deklarierte Spalte speichert es als Text, nicht als Datum. SQLite hat keinen nativen DATE– oder DATETIME-Typ – es speichert Datumsangaben als Text, reelle Zahlen (Julianischer Tag) oder Ganzzahlen (Unix-Zeitstempel). Anwendungen müssen Datumsverarbeitungskonventionen konsistent durchsetzen.

4. Der Shared-Cache-Modus ist keine Nebenläufigkeitslösung. Einige Entwickler aktivieren den Shared-Cache-Modus in der Hoffnung, die Multi-Thread-Leistung zu verbessern. In der Praxis führt er zu subtilen Sperrfehlern und wird von der SQLite-Dokumentation für die meisten Anwendungsfälle ausdrücklich abgeraten.

MySQL-Fallstricke, die in der Produktion zuschlagen

1. SELECT * auf großen Tabellen ohne LIMIT. MySQLs Query-Optimizer kann einen vollständigen Tabellen-Scan nicht immer verhindern, wenn einer Abfrage die richtige Index-Abdeckung fehlt. Führen Sie immer EXPLAIN für Abfragen vor dem Deployment durch:

EXPLAIN SELECT * FROM orders WHERE customer_email = 'user@example.com';

Ein type: ALL in der Ausgabe bedeutet einen vollständigen Tabellen-Scan – fügen Sie einen Index hinzu.

2. Implizite Commits innerhalb von Transaktionen. DDL-Anweisungen (ALTER TABLE, CREATE INDEX, DROP TABLE) geben in MySQL ein implizites COMMIT aus und beenden damit stillschweigend jede offene Transaktion. Dies ist eine häufige Quelle von Partial-Migration-Bugs.

3. Replikationsverzögerung unter schreiblastigen Workloads. MySQLs standardmäßige asynchrone Replikation bedeutet, dass Replicas unter anhaltendem Schreibdruck hinter dem Primary zurückfallen können. Anwendungen, die unmittelbar nach einem Schreibvorgang von Replicas lesen, können veraltete Daten lesen. Verwenden Sie semi-synchrone Replikation oder implementieren Sie Read-Your-Writes-Routing auf der Anwendungsschicht.

4. max_connections-Erschöpfung. Der Standard-max_connections = 151 ist für jede Anwendung mit falsch konfiguriertem Connection-Pooling gefährlich niedrig. Das Erschöpfen von Verbindungen erzeugt Too many connections-Fehler, die die Anwendung zum Absturz bringen. Setzen Sie in der Produktion immer einen Connection-Pooler (ProxySQL, PgBouncers MySQL-Fork) vor MySQL ein.

5. Zeichensatz-Kollations-Mismatches. Das Verbinden von Tabellen mit unterschiedlichen Kollationen (utf8mb4_unicode_ci vs utf8mb4_general_ci) erzwingt einen vollständigen Tabellen-Scan, indem die Index-Nutzung deaktiviert wird. Standardisieren Sie auf utf8mb4 mit utf8mb4_unicode_ci für alle Tabellen und Verbindungen.

Deployment-Architekturmuster

SQLite in einer Webanwendung: Wann es funktioniert

SQLite ist für eine Webanwendung unter spezifischen, gut verstandenen Bedingungen geeignet:

• Single-Server-Deployment mit geringer Schreib-Nebenläufigkeit: Ein persönlicher Blog, eine leselastige Dokumentationsseite oder ein internes Tool mit weniger als 10 gleichzeitigen Benutzern.
• Read-Replicas über Dateireplikation: Litestream (ein Go-basiertes SQLite-Replikationstool) streamt WAL-Frames nahezu in Echtzeit in S3-kompatiblen Objektspeicher und bietet Disaster-Recovery ohne einen MySQL-Server.
• Edge-Computing: Cloudflare D1 und Turso sind verteilte SQLite-Produkte, die das SQLite-Programmiermodell auf global verteilte Edge-Nodes bringen – eine wirklich neuartige Architektur, die MySQLs Client-Server-Modell nicht replizieren kann.

MySQL in einem skalierbaren Web-Stack

Ein produktives MySQL-Deployment für eine hochfrequentierte Webanwendung folgt typischerweise diesem Muster:

• Primary (Write) Node: Verarbeitet alle INSERT-, UPDATE-, DELETE-Operationen. Läuft auf dedizierter Hardware mit NVMe-Speicher.
• Read-Replicas (1–N): Verarbeiten SELECT-Abfragen. Read/Write-Splitting auf Anwendungsebene (über ProxySQL oder Anwendungslogik) leitet Abfragen entsprechend weiter.
• Connection-Pooler: ProxySQL sitzt zwischen der Anwendung und MySQL und verwaltet Connection-Multiplexing und Query-Routing.
• Monitoring: pt-query-digest (Percona Toolkit) analysiert Slow-Query-Logs; Prometheus mit mysqld_exporter liefert Echtzeit-Metriken.

Für Teams, die MySQL-gestützte Webanwendungen deployen, bietet ein VPS mit cPanel eine verwaltete Umgebung mit integrierten Datenbankverwaltungstools, die den Betriebsaufwand der reinen Serververwaltung reduziert. Für Anwendungen, die vollständige Kontrolle über die MySQL-Konfiguration benötigen – benutzerdefiniertes my.cnf-Tuning, spezifische Storage-Engine-Parameter oder InnoDB-Cluster-Setup – ist ein VPS mit vollem Root-Zugriff der geeignete Ausgangspunkt.

Entscheidungsmatrix: SQLite oder MySQL?

Verwenden Sie diese Matrix, um eine fundierte architektonische Entscheidung zu treffen:

Praktische wichtige Erkenntnisse

• WAL-Modus aktivieren für jede SQLite-Datenbank, die gleichzeitigen Zugriff erhält. Es ist die einzelne wirkungsvollste Konfigurationsänderung, die verfügbar ist.
• SQLite niemals dem Netzwerk aussetzen. Wenn Ihre Architektur Netzwerk-Datenbankzugriff erfordert, haben Sie SQLite bereits entwachsen – migrieren Sie zu MySQL.
• PRAGMA foreign_keys = ON setzen bei jedem SQLite-Verbindungsaufruf, nicht nur einmal bei der Datenbankerstellung.
• innodb_buffer_pool_size tunen als ersten MySQL-Optimierungsschritt. Weisen Sie 70–80 % des Server-RAM auf einem dedizierten Datenbankhost zu.
• EXPLAIN verwenden vor dem Deployment jeder nicht-trivialen MySQL-Abfrage. Ein fehlender Index auf einer Tabelle mit Millionen von Zeilen ist ein Produktionsvorfall, der darauf wartet zu passieren.
• Connection-Pooling implementieren (ProxySQL oder äquivalent), bevor MySQL 50 gleichzeitige Verbindungen erreicht. Es nachträglich unter Last einzurichten ist schmerzhaft.
• MyISAM nicht verwenden für neue MySQL-Tabellen. InnoDB ist für nahezu jeden Workload strikt überlegen und ist seit über einem Jahrzehnt der Standard.
• Für SQLite in produktiven Web-Apps sollten Sie Litestream für kontinuierliche Replikation in Objektspeicher evaluieren – es eliminiert den „Single Point of Failure”-Einwand ohne MySQLs Betriebskomplexität hinzuzufügen.
• Infrastruktur auf die Datenbank-Engine abstimmen. SQLite auf Shared-Hosting ist für Websites mit geringem Traffic in Ordnung. MySQL im großen Maßstab erfordert dedizierte Ressourcen – CPU, RAM und schnelle NVMe-I/O – die ein ordnungsgemäß bereitgestellter Dedicated Server bietet.

Häufig gestellte Fragen

Kann SQLite eine produktive Webanwendung verwalten?

Ja, unter bestimmten Bedingungen: Single-Server-Deployment, geringes gleichzeitiges Schreibvolumen (unter ~10 gleichzeitigen Schreibern) und Datensätze unter einigen Gigabytes. Hochfrequentierte Anwendungen mit mehreren Anwendungsservern können keine einzelne SQLite-Datei über ein Netzwerk teilen – das Datei-Sperrmodell bricht bei verteiltem Zugriff zusammen. Für diese Szenarien ist MySQL die richtige Wahl.

Ist SQLite ACID-konform wie MySQL?

Beide sind vollständig ACID-konform. SQLite erreicht Atomarität und Dauerhaftigkeit durch sein WAL- oder Rollback-Journal. MySQLs InnoDB-Engine verwendet Redo-Logs und MVCC. Der praktische Unterschied besteht darin, dass MySQLs Sperren auf Zeilenebene es ermöglicht, ACID-Garantien über viele gleichzeitige Transaktionen hinweg aufrechtzuerhalten, während SQLite Schreibvorgänge serialisiert.

Kann ich später von SQLite zu MySQL migrieren?

Ja, aber es erfordert sorgfältige Handhabung. SQLites dynamisches Typsystem und das Fehlen strikter Typerzwingung bedeuten, dass über .dump exportierte Daten Typ-Mismatches enthalten können, die MySQLs strikter Modus ablehnt. Tools wie pgloader (mit MySQL-Ausgabe) oder benutzerdefinierte ETL-Skripte sind typischerweise erforderlich. Planen Sie die Migration, bevor das Datenvolumen sie betrieblich schmerzhaft macht.

Benötigt MySQL einen dedizierten Server?

Nicht zwingend, aber Shared-Hosting-Umgebungen setzen Verbindungslimits, RAM-Obergrenzen und eingeschränkten my.cnf-Zugriff durch, die ein ordnungsgemäßes MySQL-Tuning verhindern. Für jede Anwendung, bei der die Datenbankleistung eine Rolle spielt, wird ein VPS oder dedizierter Server mit Root-Zugriff auf die MySQL-Konfiguration dringend empfohlen. VPS-Control-Panels können die MySQL-Verwaltung vereinfachen, ohne die Konfigurationsflexibilität zu opfern.

Was ist der Leistungsunterschied zwischen SQLite und MySQL für einen einzelnen Benutzer, der lokale Daten liest?

SQLite ist für lokale Einzelbenutzer-Lesevorgänge schneller, da es den gesamten Netzwerk-Overhead, Connection-Handshaking und Interprozesskommunikation eliminiert. Ein einfaches SELECT auf einer indizierten SQLite-Tabelle kann Ergebnisse in unter 100 Mikrosekunden zurückgeben. Die äquivalente MySQL-Abfrage über einen lokalen Unix-Socket dauert typischerweise 300–800 Mikrosekunden – immer noch schnell, aber messbar langsamer aufgrund des Client-Server-Protokoll-Overheads.