SQLite treibt Apps, Browser und Geräte weltweit an. Erfahre, warum sein eingebettetes, serverloses Design überzeugt: Einfachheit, Zuverlässigkeit, Geschwindigkeit, Portabilität — und seine Grenzen.
SQLite ist eine kleine Datenbank-Engine, die als Bibliothek verpackt ist, die Ihre Anwendung einbindet — wie ein Feature, das Sie hinzufügen, nicht ein Dienst, den Sie betreiben. Anstatt über das Netzwerk mit einer separaten Datenbankmaschine zu sprechen, liest und schreibt Ihre App in eine einzelne Datenbankdatei (oft etwas wie app.db) auf der Festplatte.
Die Idee „es ist einfach eine Datei“ ist ein großer Teil des Reizes. Die Datenbankdatei enthält Tabellen, Indizes und Daten, und SQLite übernimmt die schwierigen Aufgaben — Abfragen, Einschränkungen und ACID-Transaktionen — im Hintergrund.
Bei einer Client-Server-Datenbank (denken Sie an PostgreSQL oder MySQL) müssen Sie typischerweise:
Bei SQLite läuft die Datenbank innerhalb Ihres Anwendungsprozesses. Es gibt keinen separaten Server zu installieren, zu starten oder gesund zu halten. Ihre App ruft die SQLite-API auf, und SQLite liest/schreibt die lokale Datei direkt.
Viele beschreiben SQLite als „serverless“. Das bedeutet nicht, dass es in der Cloud ohne Server lebt — es bedeutet, Sie verwalten keinen separaten Datenbankserverprozess dafür.
SQLite taucht leise in vielen Alltagsprogrammen auf, weil es leicht auszuliefern und verlässlich ist:
Viele Produkte wählen SQLite, weil es ein unkompliziertes Default ist: schnell, stabil und ohne Konfiguration.
SQLite ist eine exzellente Wahl für viele Einzelbenutzer-Apps, eingebettete Geräte, Prototypen, die zu echten Produkten werden, und Dienste mit moderater Schreib-Konkurrenz. Aber es ist nicht die Antwort auf jedes Skalierungsproblem — besonders, wenn viele Maschinen gleichzeitig in dieselbe Datenbank schreiben müssen.
Die Kernbotschaft: SQLite ist nicht „klein“ in seinen Fähigkeiten — es ist klein im betrieblichen Aufwand. Deshalb wählen Menschen es immer wieder.
SQLite wird oft mit zwei Worten beschrieben, die nach Marketing klingen können: eingebettet und serverless. Bei SQLite haben beide spezifische (und praktische) Bedeutungen.
SQLite ist nicht etwas, das Sie im Hintergrund „ausführen“ wie PostgreSQL oder MySQL. Es ist eine Softwarebibliothek, die Ihre Anwendung einbindet und direkt verwendet.
Wenn Ihre App Daten lesen oder schreiben muss, ruft sie SQLite-Funktionen im selben Prozess auf. Es gibt keinen separaten Datenbank-Daemon zu starten, zu überwachen, zu patchen oder neu zu starten. Ihre App und die Datenbank-Engine leben zusammen.
SQLite‑„serverless" bedeutet nicht dasselbe wie die „serverless databases“, die Cloud-Anbieter vermarkten.
Bei Client-Server-Datenbanken sendet Ihr Code SQL über TCP an einen anderen Prozess. Bei SQLite führt Ihr Code SQL über Bibliotheksaufrufe aus (oft über eine Sprachbindung), und SQLite liest/schreibt die Datenbankdatei auf der Festplatte.
Das Ergebnis: kein Netzwerk-Hop, kein Connection-Pool zum Tunen und weniger Fehlerquellen (wie „Host der DB nicht erreichbar“).
Für viele Produkte bedeutet „eingebettet + serverless“ weniger bewegliche Teile:
Diese Einfachheit ist ein großer Grund, warum SQLite fast überall auftaucht — selbst wenn Teams etwas Schwereres wählen könnten.
Der am meisten unterschätzte Vorteil von SQLite ist auch der einfachste: Ihre Datenbank ist eine Datei, die mit Ihrer App mitreist. Es gibt keinen separaten Server zu provisionieren, keine Ports zu öffnen, keine Benutzerkonten anzulegen und keine „läuft die Datenbank?“‑Checkliste, bevor irgendetwas funktioniert.
Bei einer Client-Server-Datenbank bedeutet das Ausliefern einer App oft auch Infrastruktur auszuliefern: eine DB-Instanz, Migrationen, Monitoring, Credentials und einen Plan zum Skalieren. Bei SQLite packen Sie typischerweise eine initiale .db-Datei mit (oder erzeugen sie beim ersten Start) und Ihre Anwendung liest/schreibt direkt darauf.
Updates können ebenfalls einfacher sein. Brauchen Sie eine neue Tabelle oder einen Index? Sie liefern ein App-Update, das Migrationen gegen die lokale Datei ausführt. Für viele Produkte verwandelt das einen mehrstufigen Rollout in ein einziges Release-Artefakt.
Dieses „Verschicke eine Datei“-Modell glänzt, wenn die Umgebung eingeschränkt oder verteilt ist:
Eine Datenbankdatei zu kopieren klingt trivial — und kann es sein, wenn Sie es richtig machen. Sie können eine Live-Datenbankdatei nicht immer sicher mit einem naiven Datei‑Kopievorgang sichern, während die App schreibt. Nutzen Sie die Backup‑Mechanismen von SQLite (oder sichern Sie einen konsistenten Snapshot) und speichern Sie Backups an einem dauerhaften Ort.
Da es keinen Server gibt, den man tunen und babysitten muss, vermeiden viele Teams einen großen Teil des operativen Aufwands: Patches für DB‑Dienste, Connection‑Pool‑Management, Credentials‑Rotation und Replikas im grünen Bereich halten. Sie brauchen trotzdem gutes Schema‑Design und Migrationen — aber der „Datenbank‑Betrieb“-Fußabdruck ist kleiner.
Die Popularität von SQLite beruht nicht nur auf Bequemlichkeit. Ein großer Grund, warum man ihm vertraut, ist, dass es Korrektheit vor „schnellen“ Features stellt. Für viele Apps ist die wichtigste Datenbank‑Funktion simpel: keine verlorenen oder korrupten Daten.
SQLite unterstützt ACID‑Transaktionen, was kurz sagt: „Ihre Daten bleiben konsistent, auch wenn etwas schiefgeht."
SQLite erreicht Crash‑Sicherheit mithilfe eines Journals — einem Sicherheitsnetz, das aufschreibt, was sich ändern wird, damit es sauber wiederhergestellt werden kann.
Zwei gängige Modi, die Sie hören werden:
Sie müssen die Interna nicht kennen, um zu profitieren: Der Punkt ist, dass SQLite so entworfen ist, dass es vorhersehbar wiederherstellt.
Viele Anwendungen brauchen keine Cluster‑Funktionen oder exotischen Datentypen. Sie brauchen korrekte Einträge, sichere Updates und die Gewissheit, dass ein Absturz die Nutzerdaten nicht still und leise beschädigt. SQLites Fokus auf Integrität ist ein Hauptgrund, warum es in Produkten verwendet wird, in denen „langweilig und korrekt" besser ist als „beeindruckend und komplex."
SQLite wirkt oft „sofort“, weil Ihre App in‑process mit der Datenbank kommuniziert. Es gibt keinen separaten DB‑Server, keinen TCP‑Handshake und keine Netzwerklatenz. Eine Abfrage ist ein Funktionsaufruf, der von einer lokalen Datei liest (oft unterstützt durch den OS‑Page‑Cache), sodass die Zeit zwischen „SQL ausführen“ und „Zeilen zurückbekommen“ überraschend kurz sein kann.
Für viele Produkte ist die Arbeitslast hauptsächlich Lesen mit einem stetigen Tropf von Schreibvorgängen: Laden von App‑Zustand, Suchen, Filtern, Sortieren und Verbinden kleiner‑bis‑mittlerer Tabellen. SQLite ist dafür exzellent. Es kann effiziente indexbasierte Suchen, schnelle Bereichsscans und zügige Aggregationen durchführen, wenn die Daten bequem auf dem lokalen Speicher Platz finden.
Moderate Schreiblasten passen ebenfalls gut — denken Sie an Benutzereinstellungen, Hintergrund‑Sync‑Queues, zwischengespeicherte API‑Antworten, Ereignisprotokolle oder einen lokal‑first Datenspeicher, der Änderungen später zusammenführt.
Der Kompromiss von SQLite liegt in der Konkurrenz bei Schreibvorgängen. Es unterstützt mehrere Leser, aber Schreibvorgänge müssen koordiniert werden, damit die Datenbank konsistent bleibt. Bei hoher paralleler Schreiblast (viele Threads/Prozesse, die gleichzeitig aktualisieren) kann es zu Sperrkonkurrenz kommen und Sie sehen Wiederholungen oder database is busy‑Fehler, sofern Sie Verhalten und Zugriffsmuster nicht abstimmen.
SQLite ist nicht „von Haus aus schnell“, wenn Abfragen schlecht formuliert sind. Indizes, gezielte WHERE‑Klauseln, Vermeiden unnötiger Full‑Table‑Scans und passende Transaction‑Scopes machen einen großen Unterschied. Behandeln Sie es wie eine echte Datenbank — weil es eine ist.
Das markanteste Merkmal von SQLite ist auch das einfachste: Ihre gesamte Datenbank ist eine einzelne Datei (plus optionale Neben‑Dateien wie ein WAL‑Journal). Diese Datei enthält Schema, Daten, Indizes — alles, was die App braucht.
Weil sie „nur eine Datei" ist, wird Portabilität zum Standard. Sie können sie kopieren, an einen Bug‑Report anhängen, mit einem Kollegen teilen (wenn es angemessen ist) oder zwischen Maschinen verschieben, ohne einen Server, Benutzer oder Netzwerkzugang einzurichten.
SQLite läuft auf so gut wie jeder großen Plattform: Windows, macOS, Linux, iOS, Android und einer langen Liste eingebetteter Umgebungen. Diese plattformübergreifende Unterstützung kommt mit langfristiger Stabilität: SQLite ist dafür bekannt, rückwärtskompatibel zu sein, sodass eine vor Jahren erstellte Datenbankdatei meist noch von neueren Versionen gelesen werden kann.
Das Einzeldatei‑Modell ist auch eine Testing‑Superkraft. Möchten Sie einen bekannten Datensatz für Unit‑Tests? Checken Sie eine kleine SQLite‑Datei ein (oder erzeugen Sie sie während der Tests), und jeder Entwickler sowie jeder CI‑Job startet von derselben Basis. Müssen Sie ein Kundenproblem reproduzieren? Bitten Sie um die DB‑Datei (unter Berücksichtigung des Datenschutzes) und Sie können das Problem lokal nachstellen — kein „es passiert nur auf ihrem Server“-Rätsel.
Diese Portabilität hat zwei Seiten: Wenn die Datei gelöscht oder korrupt ist, sind die Daten weg. Behandeln Sie die SQLite‑Datenbank wie jeden wichtigen Anwendungsbestandteil:
SQLite ist leicht zu erlernen, teilweise weil Sie selten bei null anfangen. Es ist in vielen Plattformen eingebaut, wird mit gängigen Laufzeitumgebungen geliefert und bietet „langweilige“ Kompatibilität über Umgebungen hinweg — genau das, was man von einer eingebetteten Datenbank erwartet.
Die meisten Stacks haben bereits einen gut befahrenen Weg zu SQLite:
sqlite3 in der Standardbibliothek), Go (mattn/go-sqlite3), Java (JDBC‑Treiber), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).Diese Breite ist wichtig, weil Ihr Team vertraute Muster nutzen kann — Migrationen, Query‑Builder, Connection‑Handling — ohne eigenes Plumbing zu erfinden.
Die Tooling‑Landschaft von SQLite ist ungewöhnlich zugänglich. Die sqlite3 CLI macht es einfach, Tabellen zu inspizieren, Abfragen auszuführen, Daten zu dumpen oder CSV zu importieren. Für visuelle Explorationen helfen Browser‑basierte und Desktop‑Viewer (zum Beispiel SQLiteStudio oder DB Browser for SQLite) Nicht‑Spezialisten, Daten schnell zu validieren.
Auf der Auslieferungsseite unterstützen gängige Migrationstools SQLite oft out‑of‑the‑box: Rails‑Migrationen, Django‑Migrationen, Flyway/Liquibase, Alembic und Prisma Migrate machen Schema‑Änderungen wiederholbar.
Weil SQLite so weit verbreitet ist, sind Probleme meist gut verstanden: Bibliotheken werden ausgiebig getestet, Randfälle dokumentiert und Community‑Beispiele sind zahlreich. Diese Popularität erzeugt mehr Support, was die Adoption weiter erleichtert.
Wenn Sie eine Bibliothek wählen, bevorzugen Sie aktiv gepflegte Treiber/ORM‑Adapter für Ihren Stack und prüfen Sie das Concurrency‑Verhalten, Binding‑Support und wie Migrationen gehandhabt werden. Eine gut unterstützte Integration ist oft der Unterschied zwischen einem reibungslosen Rollout und einem Wochenend‑Einsatz zur Fehlerbehebung.
SQLite versteht man am besten, wenn man anschaut, wo es tatsächlich eingesetzt wird: Orte, an denen ein vollständiger Datenbankserver Kosten, Komplexität und Fehlerfälle hinzufügen würde.
Viele mobile Apps benötigen einen verlässlichen lokalen Speicher für Sitzungen, gecachte Inhalte, Notizen oder Queues von „Dingen, die später hochgeladen werden sollen“. SQLite passt, weil es eine Einzeldatei‑Datenbank mit ACID‑Transaktionen ist, sodass Ihre Daten Abstürze, niedrigen Akku und unzuverlässige Verbindung überstehen.
Das ist besonders stark bei Offline‑first und Lokal‑first Apps: jede Änderung lokal schreiben und später im Hintergrund synchronisieren, wenn das Netzwerk verfügbar ist. Der Vorteil ist nicht nur Offline‑Support — es ist eine schnelle UI und vorhersehbares Verhalten, weil Lese‑ und Schreibzugriffe auf dem Gerät bleiben.
Desktop‑Software braucht oft eine Datenbank, ohne den Nutzer zu fragen. Eine einzelne SQLite‑Datei ausliefern (oder beim ersten Start erzeugen) hält die Installation simpel und macht Backups verständlich: eine Datei kopieren.
Programme wie Buchhaltungssoftware, Medienmanager und leichte CRM‑Systeme nutzen SQLite, um Daten nah an der App zu halten, was die Performance steigert und Probleme wie „läuft der DB‑Server?“ vermeidet.
SQLite taucht in Entwickler‑Tools und Anwendungen auf, die strukturierte Speicherung für Historien, Indizes und Metadaten brauchen. Es ist hier beliebt, weil es stabil, portabel und kein separater Prozess ist.
Router, Kiosks, POS‑Terminals und IoT‑Gateways speichern oft Konfiguration, Logs und kleine Datensätze lokal. SQLites geringer Fußabdruck und dateibasierte Portabilität machen es praktisch für den Einsatz und Updates.
Entwickler nutzen SQLite für schnelle Prototypen, lokale Entwicklungsdatenbanken und Test‑Fixtures. Es ist zero‑setup, leicht zurücksetzbar und deterministisch — Vorteile, die zu schnellerer Iteration und zuverlässigeren CI‑Runs führen.
Das ist auch ein übliches Muster beim Arbeiten mit Koder.ai: Teams starten mit SQLite für schnelle lokale Iteration (oder ein Single‑Tenant‑Deployment) und exportieren später den generierten Quellcode und wechseln zu PostgreSQL, wenn das Produkt geteilte, multi‑writer Skalierung benötigt. Dieser „einfach starten, später migrieren“‑Workflow hält frühe Lieferungen schnell, ohne in eine Sackgasse zu manövrieren.
SQLite ist ein großartiges Default für lokale Speicherung, aber es ist kein Allheilmittel. Entscheiden Sie nach Ihrer Arbeitslast und den betrieblichen Anforderungen — nicht nach Hype.
SQLite kann mehrere Leser gut handhaben, aber Schreibvorgänge sind eingeschränkter, weil Änderungen letztlich serialisiert werden müssen, um die Datei konsistent zu halten. Wenn viele Nutzer oder Prozesse gleichzeitig Daten verändern — besonders von unterschiedlichen Maschinen — ist eine Client‑Server‑Datenbank (wie PostgreSQL oder MySQL) meist passender.
Ein typisches Anzeichen ist: „auf dem Laptop funktioniert alles“, aber unter realer Nutzung treten Timeouts, Sperrkonkurrenz oder aufbauende Schreib‑Queues auf.
SQLite kann sehr schnell sein, ist aber für eine andere Arbeitslast optimiert: viele Lesevorgänge und moderate Schreibfrequenz. Wenn Ihr System viele Inserts/Updates in hoher Frequenz ausführt (Metriken‑Ingestion, Event‑Streams, Job‑Queues, volumenstarke Logs) und viele parallele Schreiber erwartet, skaliert eine Server‑DB vorhersehbarer.
Dabei geht es nicht nur um „Geschwindigkeit“. Es geht auch um latenzkonsistente Antworten: ein Schreibschub kann andere Schreiber und manchmal auch Leser blockieren, was zu Tail‑Latencies führt, die schwer zu erklären sind.
Wenn Sie eine zentrale Datenbank brauchen, die über das Netzwerk geteilt wird, mit rollenbasierter Berechtigung, Audit‑Trails, zentralen Backups und Governance‑Funktionen, ist SQLite wahrscheinlich das falsche Werkzeug. Sie können eine SQLite‑Datei auf einem Netzlaufwerk ablegen, aber das führt oft zu Zuverlässigkeits‑ und Sperrproblemen.
Ein Server‑DB ist überlegen, wenn Sie brauchen:
Stellen Sie zwei Fragen:
Wenn die ehrliche Antwort "viele Schreiber" und "zentrale Governance" ist, ist eine Client‑Server‑Datenbank meist die sicherere Wahl.
SQLite und Datenbanken wie PostgreSQL oder MySQL können beide Tabellen speichern und SQL ausführen, aber sie sind für unterschiedliche Problemformen gebaut.
SQLite läuft im Prozess Ihrer Anwendung. Ihr Code ruft SQLite auf und SQLite liest/schreibt direkt in eine lokale Datenbankdatei.
Eine Client‑Server‑Datenbank läuft als separater Dienst. Ihre App verbindet sich über das Netzwerk (auch wenn das Netzwerk nur localhost ist), sendet Abfragen und der Server verwaltet Speicherung, Konkurrenz, Benutzer und Hintergrundarbeit.
Dieser Unterschied erklärt die meisten praktischen Kompromisse.
Mit SQLite kann das Deployment so einfach sein wie ein Binary plus eine Datei. Keine Ports, keine Credentials, keine Server‑Upgrades — oft ein großer Gewinn für Desktop‑, Mobile‑, Edge‑Apps und lokal‑first Produkte.
Client‑Server‑Datenbanken glänzen, wenn Sie zentrale Verwaltung brauchen: viele Apps und Nutzer, die dieselbe Datenbank anfragen, feingranulare Zugriffskontrolle, Online‑Backups, Lesereplikate und ausgereifte Observability.
SQLite skaliert typischerweise durch:
Client‑Server‑Datenbanken skalieren einfacher für geteilte Workloads durch größere Maschinen, Replikation, Partitionierung und Pooling.
Wählen Sie SQLite, wenn Sie lokale Daten, minimale Ops und eine einzige Applikationsinstanz, die Schreibvorgänge besitzt, wollen.
Wählen Sie eine Client‑Server‑DB, wenn Sie viele gleichzeitige Schreiber, netzwerkbasierten Zugriff von mehreren Services, zentrale Governance oder eingebaute Hochverfügbarkeit brauchen.
Wenn Sie unsicher sind, starten Sie mit SQLite für schnelle Lieferung und halten Sie einen klaren Migrationspfad (Schemas, Migrationen, Export/Import) zu PostgreSQL bereit (/blog/migrating-from-sqlite).
SQLite kann gut in Produktion laufen — behandeln Sie es wie eine echte Datenbank, nicht als „temporäre Datei, die man herumkopiert“. Ein paar Gewohnheiten machen den Unterschied zwischen stabilem Betrieb und unangenehmen Überraschungen.
SQLite unterstützt mehrere Leser und (normalerweise) einen Schreiber gleichzeitig. Das ist in vielen Apps in Ordnung, solange Sie dafür designen.
Halten Sie Schreib‑Transaktionen kurz und fokussiert: bereiten Sie die Arbeit in Ihrer App vor, öffnen Sie dann die Transaktion, schreiben Sie und commiten Sie schnell. Vermeiden Sie langlaufende Transaktionen, die Sperren halten, während Sie auf Netz‑Aufrufe, Benutzer‑Eingaben oder langsame Schleifen warten. Falls Sie Hintergrundjobs haben, queueen Sie Schreibvorgänge, damit sie sich nicht ansammeln und interaktive Anfragen blockieren.
Write‑Ahead Logging (WAL) ändert, wie SQLite Änderungen aufzeichnet, sodass Leser oft weiterlesen können, während ein Schreiber aktiv ist. Für viele Apps — besonders solche mit vielen Lesern und gelegentlichen Schreibvorgängen — reduziert WAL die "database is locked"‑Reibung und verbessert Durchsatz.
WAL ist kein Allheilmittel: Sie haben weiterhin einen Schreiber, und Sie müssen die zusätzlichen WAL‑Dateien auf der Festplatte einkalkulieren. Trotzdem ist es ein gängiger, praktischer Default für Produktions‑Deployments.
Auch wenn SQLite eine einzelne Datei ist, brauchen Sie eine Backup‑Strategie. Kopieren Sie die Datei nicht ungeplant; koordinieren Sie Backups, um einen konsistenten Zustand zu erfassen (besonders unter Last).
Verwalten Sie Schema‑Änderungen mit Migrationen. Versionieren Sie sie, führen Sie sie automatisch während Deploys aus und testen Sie Rollback/Forward‑Pfade, wenn möglich.
Nutzen Sie dasselbe Schema, Indizes und kritische Einstellungen (z. B. Journal‑Modus) in Staging und automatisierten Tests. Viele SQLite‑Überraschungen treten erst auf, wenn Datenmengen oder Concurrency wachsen — führen Sie daher Lasttests mit realistischen Volumen und Zugriffsmustern durch, bevor Sie live gehen.
SQLite ist überall, weil es das Speichern von Daten wie das Verwenden einer Bibliothek erscheinen lässt, nicht wie das Betreiben von Infrastruktur. Sie bekommen eine erprobte SQL‑Engine, ACID‑Transaktionen und ausgereifte Tools — ohne einen Datenbankserver zu provisionieren, Benutzer zu verwalten oder eine Netzwerkverbindung zu babysitten.
Im besten Fall ist SQLite die "funktioniert einfach"‑Option:
SQLite ist nicht für hohe Schreibkonkurrenz oder zentralisierten, multi‑user Netzwerkzugriff ausgelegt. Viele Leser können gleichzeitig abfragen, aber starke parallele Schreibzugriffe (oder viele Clients, die dieselbe Datei teilen) sind der Punkt, an dem eine Client‑Server‑Datenbank meist die sicherere Wahl ist.
Beschreiben Sie Ihre Arbeitslast — und wählen Sie dann das einfachste Werkzeug, das passt. Wenn Ihre App überwiegend lokal, Einzelbenutzer oder „lokal‑first“ ist, ist SQLite oft perfekt.
Wenn Sie die ersten vier mit „ja" und die letzte mit „nein" beantworten, ist SQLite eine starke Default‑Option.
SQLite ist eine eingebettete Datenbank-Engine: Sie läuft im Prozess Ihrer Anwendung als Bibliothek. Ihre App liest und schreibt direkt in eine einzelne Datenbankdatei (zum Beispiel app.db) auf der Festplatte – es gibt keinen separaten DB-Dienst, den man installieren oder verwalten muss.
„Serverless“ bei SQLite bedeutet, dass kein separater Datenbankserverprozess vorhanden ist. Es heißt nicht „läuft in der Cloud ohne Server“. Ihre Anwendung ruft die SQLite-API im eigenen Prozess auf, und SQLite speichert die Daten lokal in einer Datei.
In der Regel müssen Sie nichts bereitstellen: Sie liefern Ihre App mit einer initialen .db-Datei aus (oder erstellen sie beim ersten Start) und führen Migrationen als Teil von App-Updates aus. Das verwandelt oft einen mehrstufigen Infrastruktur-Rollout in ein einziges Release-Artefakt.
Ja. SQLite unterstützt ACID-Transaktionen, die helfen, partielle Schreibvorgänge und Korruption bei Abstürzen oder Stromausfall zu verhindern.
SQLite verwendet üblicherweise ein Journal, um nach Unterbrechungen sicher wiederherstellen zu können.
Viele Produktionssysteme wählen WAL, weil es häufig die „database is locked“-Reibung reduziert.
Weil SQLite im Prozess läuft: Abfragen sind Funktionsaufrufe, keine Netzwerk-Roundtrips. In Kombination mit lokalem Speicher und OS-Page-Cache wirken viele leseintensive Workloads (Suche, Filter, indexbasierte Abfragen) sehr schnell – besonders für Desktop-, Mobile- und lokal-first-Apps.
SQLite unterstützt mehrere Leser, aber Schreibvorgänge müssen koordiniert werden, damit die Datei konsistent bleibt. Bei intensiven parallelen Schreibzugriffen kann es zu Sperrkonkurrenz und Fehlern wie database is busy / database is locked kommen, sofern Sie nicht serialisierte Schreibmuster und kurze Transaktionen verwenden.
SQLite ist ungeeignet, wenn viele Maschinen/Services gleichzeitig auf dieselbe zentrale Datenbank schreiben müssen oder wenn Sie zentrale Governance brauchen.
Wählen Sie einen Client-Server-DB (z. B. PostgreSQL/MySQL), wenn Sie brauchen:
Behandeln Sie die Datenbank wie wichtigen Anwendungsdaten:
Beginnen Sie mit SQLite, wenn Ihre App lokal, Einzelbenutzer oder schreibarme Workloads hat, und halten Sie einen klaren Migrationspfad bereit.
Praktische Tipps:
/blog/migrating-from-sqlite