SQLite als WordPress-Datenbank: Entwicklungsstand, Grenzen und Einsatzfälle

WordPress und SQLite richtig einordnen

WordPress unterstützt SQLite derzeit nicht als regulär auswählbare Datenbankplattform im Core. Die offiziellen Systemanforderungen nennen weiterhin MySQL oder MariaDB; SQLite gehört nicht zu den Standardvoraussetzungen einer WordPress-Installation. Wer WordPress mit SQLite betreibt, wechselt deshalb nicht einfach eine Core-Einstellung, sondern ergänzt WordPress um eine eigene Integrationsschicht.

Diese Schicht stellt das Plugin SQLite Database Integration bereit. Es ist im WordPress.org-Plugin-Verzeichnis verfügbar und wird als Community- beziehungsweise Feature-Plugin entwickelt. Sein Ziel ist, eine SQLite-Implementierung zu erproben und Rückmeldungen für eine mögliche spätere Core-Integration zu sammeln. Die Präsenz im WordPress.org-Ökosystem ist damit keine Freigabe als fester Bestandteil einer normalen WordPress-Installation.

Die Initiative hat einen längeren Vorlauf: Im September 2022 wurde im WordPress-Core-Team öffentlich vorgeschlagen, SQLite langfristig offiziell zu unterstützen. Seit Januar 2023 lässt sich die Implementierung als eigenständiges Plugin beziehen; die damalige Verbindung zu Performance Lab beschreibt einen Entwicklungsschritt, nicht den heutigen Standardweg für jede WordPress-Website.

Für eine belastbare Einordnung zählt der Versionsstand. Zum Recherchezeitpunkt 18. Oktober 2026 ist v3.1.0 vom 8. Oktober 2026 die stabile Release-Version. Aussagen aus dem Entwicklungszweig dürfen nicht ohne Weiteres als Eigenschaften dieser stabilen Version gelten. Umgekehrt wäre es falsch, das aktive Plugin allein deshalb mit einer allgemeinen Produktivfreigabe für jeden WordPress-Anwendungsfall gleichzusetzen.

Die Leserfrage lässt sich daher nur bedingt mit Ja beantworten: SQLite kann für klar abgegrenzte Installationen sinnvoll sein, etwa für Entwicklung, Demos oder kleine Einzelserver-Websites mit überschaubaren Änderungen. Für verteilte, schreibintensive oder geschäftskritische Installationen bleiben MySQL oder MariaDB die regulär unterstützte und meist passendere Grundlage. Entscheidend sind Architektur, Schreibmuster und die tatsächliche Kompatibilität des eingesetzten Stacks.

Dateidatenbank, Drop-in und SQL-Kompatibilität

Der grundlegende Unterschied liegt im Speichermodell. SQLite ist eine Dateidatenbank: Die Daten liegen lokal in einer Datenbankdatei auf dem Dateisystem. MySQL und MariaDB arbeiten dagegen als eigenständige Datenbankdienste, mit denen WordPress über eine Serververbindung kommuniziert. SQLite kann deshalb eine schlankere Umgebung ermöglichen, setzt aber einen geeigneten lokalen Speicherort und passende Dateirechte voraus.

WordPress-Core, Themes und die meisten Erweiterungen verwenden für Datenbankzugriffe die bekannte Schnittstelle wpdb. Das Plugin ersetzt die übliche Datenbankschicht über das Drop-in wp-content/db.php. Dieses Drop-in fängt die Abfragen ab und vermittelt zwischen der erwarteten MySQL-orientierten WordPress-Welt und SQLite. Damit bleibt die Anwendungsoberfläche für viele Komponenten gleich, obwohl sich der Datenbankunterbau ändert.

Der Vermittlungs-Layer ist der entscheidende Punkt hinter der verkürzten Aussage „WordPress läuft auf SQLite“. WordPress erzeugt nicht automatisch SQLite-spezifisches SQL. Die Projektdokumentation im Entwicklungszweig trunk beschreibt einen MySQL-Parser, der SQL-Grammatik und benötigte Funktionen für SQLite nachbildet. Das erläutert den Entwicklungsansatz, ist aber weder eine stabile Versionszusage noch eine Garantie, dass jede individuelle MySQL-Abfrage oder Erweiterung ohne Anpassung kompatibel ist.

Besonders sorgfältig prüfen solltest du Erweiterungen, die SQL direkt erzeugen, Datenbankfunktionen voraussetzen oder eigene Tabellen ungewöhnlich verwalten. Das betrifft ebenso Importer, Reporting-Werkzeuge und Wartungsskripte. Ein Theme oder Plugin kann im Standardbetrieb funktionieren und dennoch bei einem seltenen Admin-Vorgang, einem Update oder einer speziellen Abfrage an einer nicht abgebildeten MySQL-Eigenheit scheitern.

Die Unterschiede bei Schema, Metadaten und typischen Abfragen bleiben für die Bewertung relevant. Der interne Überblick zu WordPress-Datenbanktabellen und ihrer Performance hilft dabei, datenbankintensive Erweiterungen und eigene Tabellen als mögliche Prüfstellen einzuordnen. SQLite Integration ersetzt weder eine Analyse solcher Abfragen noch die Verantwortung, Anpassungen außerhalb der WordPress-Standardschnittstelle vor dem Einsatz zu testen.

Wann SQLite technisch vertretbar ist

Eine sinnvolle Entscheidung folgt nicht aus einer pauschalen Besucherzahl. Maßgeblich ist die Schreibkonkurrenz: SQLite lässt mehrere parallele Leser zu, aber pro Datenbankdatei kann jeweils nur ein Schreibvorgang stattfinden. Treffen Änderungen zeitlich zusammen, müssen weitere Schreibvorgänge warten. Die SQLite-Dokumentation rät bei vielen unabhängigen Clients, mehreren Rechnern oder vielen gleichzeitigen Schreibvorgängen zu einer Client-Server-Datenbank.

Gut abgrenzbare Einsatzfelder sind lokale Entwicklung, Schulungen, Demos und kurzlebige Testinstanzen. Dort entfällt die Einrichtung eines separaten MySQL- oder MariaDB-Dienstes, während sich der Plugin- und Theme-Stack kontrolliert prüfen lässt. Auch eine kleine Website auf einem einzelnen Server kann passen, wenn sie überwiegend gelesen wird und redaktionelle Änderungen selten sowie zeitlich nicht geballt erfolgen.

Eine schlanke Firmenwebsite, ein persönlicher Blog oder eine Kampagnenseite sind jedoch nicht automatisch geeignet. Kontaktformulare, Mitgliederbereiche, Newsletter-Anbindungen oder individuell programmierte Endpunkte können zusätzliche Schreibvorgänge auslösen. Prüfe daher nicht nur Seitenaufrufe, sondern auch Aktualisierungen von Optionen, Formulareingänge, geplante Aufgaben sowie Datenänderungen durch Plugins und externe Schnittstellen.

Für Shops mit Bestellungen, Buchungs- und Ticketing-Systeme, aktive Communities oder Anwendungen mit vielen AJAX- und REST-Schreibvorgängen ist die Einschränkung meist gewichtiger. Dort können mehrere Nutzende nahezu gleichzeitig Bestellungen speichern, Verfügbarkeiten ändern oder Beiträge erstellen. Mehrere Webserver hinter einem Load Balancer passen ebenfalls nicht zum lokalen Dateiansatz, den SQLite für diesen Anwendungsfall voraussetzt.

Caching löst eine andere Aufgabe als SQLite. Seiten- oder Objekt-Caching kann wiederkehrende Lesezugriffe und damit Datenbankabfragen reduzieren; es macht eine schreibintensive Anwendung aber nicht zu einer konfliktarmen SQLite-Installation. Umgekehrt ersetzt SQLite kein Cache-Konzept. Für bestehende Websites kann das Beibehalten von MySQL oder MariaDB zusammen mit geeignetem Caching deshalb der risikoärmere Weg sein, ohne die Datenbankplattform zu wechseln.

Szenarien mit SQLite systematisch bewerten

Ob SQLite für WordPress passt, entscheidet nicht eine Besucherzahl, sondern das Zusammenspiel aus Schreibvorgängen, Serveraufbau und Erweiterungen. SQLite kann parallele Lesezugriffe bedienen, aber Schreibvorgänge auf derselben Datenbankdatei nicht beliebig parallel ausführen. Deshalb ist eine einzelne Website mit vielen Seitenaufrufen nicht automatisch ungeeignet, während zeitgleich ausgelöste Bestellungen oder Buchungen kritisch sein können.

Die Tabelle ist eine Vorauswahl, keine Freigabe. Besonders bei einer kleinen Firmenwebsite können ein CRM-Formular, ein Mitgliederbereich oder ein externer Automatisierungsdienst aus einer selten schreibenden Seite einen Schreiblastfall machen. Umgekehrt bleibt ein Blog mit vielen Lesern ein plausibler Kandidat, wenn Kommentare, Formulare und administrative Änderungen überschaubar sind. Das Plugin verweist selbst darauf, dass die Eignung von Traffic und Schreiblast abhängt.

Multisite ist in der Projektdokumentation des Entwicklungszweigs als einrichtbares Szenario beschrieben; außerdem enthält das Repository dazu eigene Tests. Daraus folgt jedoch keine allgemeine Produktionsfreigabe für große Netzwerke mit vielen Redakteuren, Sites oder Integrationen. Behandle ein Netzwerk daher als eigenständigen Kompatibilitätsfall und prüfe die tatsächlich genutzten Verwaltungs-, Update- und Inhaltsabläufe.

Der verbindliche Praxisschritt ist ein Test des konkreten Stacks in einer getrennten Umgebung. Dazu gehören das aktive Theme, alle produktiven Plugins, individuelle MU-Plugins, Importer, Formulare, REST-Endpunkte sowie Sicherungs- und Monitoring-Werkzeuge. Entscheidend ist nicht nur, ob Seiten laden: Jede Erweiterung mit eigenen SQL-Annahmen oder häufigen Änderungen muss die SQLite-Schicht zuverlässig durchlaufen.

Einrichtung und sichere Pfadkonfiguration

Die Einrichtung eignet sich für eine neue Testinstallation oder eine bewusst geplante SQLite-Installation, nicht als Schnellschalter für eine bestehende Produktion. Vor der Aktivierung muss PHP die Erweiterung pdo_sqlite samt PDO-Unterstützung bereitstellen; außerdem verlangt das Plugin SQLite ab Version 3.37.0. PHP benötigt Schreibrechte für das gewählte Datenbankverzeichnis. Der Einrichtungsdialog prüft diese Bedingungen und erkennt zudem vorhandene, kollidierende Datenbank-Drop-ins.

Die angegebene SQLite-Mindestversion ist eine technische Plugin-Anforderung, aber keine pauschale Zusage für jeden produktiven Anwendungsfall. Seit Plugin-Version 3.0 ist Write-Ahead Logging standardmäßig aktiviert. Betreiber sollten deshalb kontrollieren, welche SQLite-Bibliothek die verwendete PHP-Laufzeit tatsächlich lädt, und Plugin-, PHP- sowie SQLite-Aktualisierungen in ihre Wartungs- und Kompatibilitätsprüfungen einbeziehen.

Prüfe besonders wp-content/db.php. Diese Datei ist das zentrale WordPress-Drop-in für die Datenbankschicht; zwei Lösungen können sie nicht gleichzeitig verwenden. Existiert dort bereits ein Drop-in etwa für eine andere Datenbankanbindung oder eine Caching-Lösung, muss vor der Installation geklärt werden, welche Komponente es bereitstellt und ob ein sauberer Rückbau möglich ist.

Die stabile Version 3.1.0 verwendet standardmäßig zufällig benannte Unterverzeichnisse unter wp-content/database/. Der ermittelte Speicherort wird in db-path.php festgehalten und über DB_PATH bereitgestellt. Backup- und Migrationswerkzeuge dürfen daher keinen historischen Dateinamen oder einen geratenen Standardpfad voraussetzen. Die früheren Konstanten DB_DIR und DB_FILE sind in 3.1 als veraltet markiert; DB_PATH hat Vorrang.

Für eine geplante Neuinstallation empfiehlt das Projekt einen absoluten Pfad außerhalb des öffentlich erreichbaren Webverzeichnisses. Das Zielverzeichnis muss für den PHP-Prozess schreibbar sein. Die folgende Einstellung gehört in wp-config.php und ist ein Konfigurationsbeispiel, keine Anweisung zur nachträglichen Umstellung einer laufenden Website.

// Dateikonfiguration wp-config.php:
// Beispielpfad außerhalb des öffentlich erreichbaren Webverzeichnisses.
define( 'DB_PATH', '/private/wordpress/database.sqlite' );

Warnung: Ein neu gesetzter DB_PATH verschiebt keine vorhandene Datenbankdatei. Er wählt einen anderen Speicherort aus. Wird der Wert unvorbereitet geändert, kann WordPress daher eine andere oder leere Datenbank verwenden. Plane den Pfad, die Zugriffsrechte, die Sicherung und einen Wiederherstellungstest vor dem produktiven Einsatz gemeinsam.

Die zufällige Verzeichnisstruktur in Version 3.1 reduziert lediglich die Vorhersehbarkeit des Standardpfads. Sie ersetzt weder Dateisystemrechte noch einen verlässlich gegen öffentliche Auslieferung geschützten Speicherort. Am sichersten ist der empfohlene Pfad außerhalb des Webroots; wird eine andere Ablage gewählt, muss der Webserverzugriff darauf ebenso zuverlässig ausgeschlossen sein.

Kein Datenbankwechsel per Aktivierung

Bei einer bestehenden WordPress-Website mit MySQL oder MariaDB ist das Aktivieren von SQLite Database Integration keine Migration. Das Plugin erstellt eine separate, zunächst leere SQLite-Datenbank. Beiträge, Benutzer, Optionen, Medienverweise und Plugin-Daten aus der bisherigen Datenbank werden nicht automatisch übernommen. Wird die Integration später deaktiviert, verbindet sich WordPress wieder mit der bisherigen Datenbank; in SQLite entstandene Änderungen werden nicht zurückübertragen.

Diese Trennung ist für Tests nützlich, aber für produktive Umstellungen wesentlich. Wer Inhalte tatsächlich auf eine andere Datenbankplattform überführen will, braucht einen eigenen, nachvollziehbaren Migrationsplan einschließlich Datenübernahme, Prüfung von Zeichensätzen und Optionen sowie eines Rückfallwegs. Das bloße Umschalten des Drop-ins kann diesen Prozess nicht ersetzen.

Die Bezeichnung separate Datenbestände ist hier wörtlich zu verstehen: Während des SQLite-Betriebs können beide Datenbanken unterschiedliche Inhalte enthalten. Ein Testbeitrag in SQLite erscheint nach dem Deaktivieren nicht plötzlich in MySQL oder MariaDB. Ebenso bleibt ein neuer MySQL-Beitrag unsichtbar, solange WordPress die SQLite-Datei als aktive Datenquelle nutzt.

Das Repository wp-sqlite-db bezeichnet sich selbst als eigenständiges Projekt mit einem einzelnen SQLite-Drop-in und verweist auf die ursprüngliche SQLite-Integration. Es ist daher nicht mit dem aktuellen WordPress-Repository gleichzusetzen. Dateien, Konfigurationswerte und Anleitungen aus diesem Projekt sollten nicht auf die aktuelle SQLite Database Integration übertragen werden; maßgeblich ist jeweils die Dokumentation des konkret eingesetzten Projekts.

Für bestehende Websites ist häufig die risikoärmere Entscheidung, MySQL oder MariaDB beizubehalten und Engpässe separat zu untersuchen. Seiten- oder Objekt-Caching kann Datenbankabfragen reduzieren, ersetzt aber keine Datenmigration und löst keine Kompatibilitätsfrage der SQLite-Integration. Für die Einordnung typischer WordPress-Abfragen und Caching-Ansätze hilft dieser Überblick zur WordPress-Performance und Caching-Optimierung.

SQLite-Datenbank schützen und konsistent sichern

Bei SQLite liegt der WordPress-Datenbestand in einer Datei auf dem Server. Sie kann unter anderem Inhalte, Benutzerkonten, Optionen und Konfigurationsdaten enthalten und ist deshalb wie ein Datenbankserver zu schützen. Ein zufällig benanntes Standard-Unterverzeichnis, das Version 3.1 verwendet, erschwert lediglich das Erraten eines Pfads; es ersetzt keine korrekt eingerichteten Dateirechte und keine Zugriffsbeschränkung des Webservers.

Das Projekt empfiehlt, DB_PATH als absoluten Pfad außerhalb des Webroots festzulegen. PHP benötigt dort Schreibrechte, während der Webserver die Datenbankdatei nicht direkt ausliefern darf. Diese Trennung reduziert das Risiko, dass eine Fehlkonfiguration innerhalb des öffentlich erreichbaren Verzeichnisses die Datei zugänglich macht. Deployment, Rechteverwaltung und Sicherung müssen den gewählten Speicherort ausdrücklich berücksichtigen.

Für Backups ist seit der Release-Linie 3.1 entscheidend, keinen historischen Dateinamen und keinen geratenen Standardpfad fest einzutragen. Das Plugin kann den tatsächlichen Pfad über DB_PATH zur Laufzeit verfügbar machen; Backup-, Migrations- und Wiederherstellungswerkzeuge müssen ihn deshalb nach dem Laden von WordPress ermitteln. Vor einer Freigabe solltest du die Wiederherstellung in einer getrennten Umgebung durchführen und den dafür erforderlichen Pfad, die Konfiguration und die Arbeitsschritte dokumentieren.

Seit Plugin-Version 3.0 verwendet die Integration standardmäßig den WAL-Modus. Dabei können neben der Hauptdatenbank Begleitdateien mit den Endungen -wal und -shm entstehen. Prüfe deshalb ausdrücklich, ob das verwendete Sicherungswerkzeug den WAL-Betrieb der laufenden SQLite-Datenbank unterstützt und diese Bestandteile berücksichtigt. Aus dem bloßen Kopieren der Hauptdatei lässt sich ohne eine solche Werkzeugfreigabe keine konsistente Sicherung ableiten.

Die vom Plugin genannte Mindestversion SQLite 3.37.0 beschreibt die technische Untergrenze der Integration. Für den Betrieb solltest du zusätzlich verfolgen, welche SQLite-Version PHP tatsächlich verwendet, und Sicherheits- sowie Fehlerkorrekturen der eingesetzten PHP- und SQLite-Pakete in den regulären Aktualisierungsprozess aufnehmen. Ohne eine passende Quelle im vorhandenen Quellenbestand lässt sich daraus jedoch keine belastbare Empfehlung für einzelne darüberliegende SQLite-Versionen oder bestimmte Backports ableiten.

Export- und Backup-Werkzeuge sollten nicht allein deshalb eingesetzt werden, weil sie aus MySQL- oder MariaDB-Installationen bekannt sind. Prüfe für das konkrete Werkzeug, ob es die SQLite-Datenbank am aktuellen DB_PATH und im konfigurierten Journalmodus unterstützt. Führe anschließend eine Wiederherstellung in der vorgesehenen Hosting-Umgebung durch und dokumentiere, ob Datenbankpfad, erforderliche Datenbankbestandteile und WordPress-Konfiguration vollständig zusammengeführt werden.

Konflikte erkennen und gezielt prüfen

Die Umstellung gehört zunächst in eine Staging- oder Testinstanz, nicht in den ersten produktiven Rollout. Erfasse vor der Installation vorhandene Dateien unter wp-content/db.php sowie Plugins, MU-Plugins und individuelle Erweiterungen mit direkten MySQL-Annahmen. Ein zweites Datenbank-Drop-in kann nicht parallel arbeiten; der Einrichtungsprozess der Integration prüft daher auf solche Kollisionen.

Prüfe danach konkrete Abläufe statt nur die Startseite: Anmeldung und Administration, Inhaltserstellung, Suche, Formulare, geplante Aufgaben, Import und Export sowie Backup und Wiederherstellung. Wiederhole die Tests nach Plugin- und WordPress-Updates. Die Integrationsschicht verarbeitet MySQL-Syntax für SQLite, doch die projektseitig beschriebene Unterstützung ersetzt keine Prüfung eigener Abfragen oder seltener Funktionen einer Erweiterung.

Häufige Einrichtungsfehler sind fehlendes pdo_sqlite beziehungsweise pdo oder unzureichende Schreibrechte für das Datenbankverzeichnis. Ebenso problematisch ist die Annahme, die Aktivierung übernehme Inhalte einer bestehenden MySQL- oder MariaDB-Installation: Sie erzeugt eine getrennte SQLite-Datenbank, nicht automatisch eine Datenmigration. Auch ein neuer DB_PATH verschiebt keine vorhandene Datei, sondern verweist auf einen anderen Ort.

Treten unter Last Wartezeiten auf, untersuche zuerst, welche Aktionen gleichzeitig schreiben: etwa Bestellungen, Formularverarbeitung, REST-Anfragen oder Hintergrundaufgaben. SQLite erlaubt mehrere Leser, serialisiert aber Schreibvorgänge pro Datenbankdatei; mehrere Webserver erhöhen zudem die Anforderungen an die Datenbankarchitektur. Das ist nicht mit den Sperrmechanismen von MySQL-InnoDB gleichzusetzen. Für die Ursachenanalyse bei herkömmlichen WordPress-Datenbanken hilft der Beitrag zu gleichzeitigen Datenbankzugriffen und Locks.

Die passende Datenbankstrategie auswählen

SQLite ist für WordPress vertretbar, wenn die Website auf einem einzelnen System läuft, überwiegend gelesen wird und gleichzeitige Änderungen begrenzt und bekannt sind. Dazu passen lokale Entwicklung, Demos oder kleine redaktionelle Websites eher als transaktionsreiche Anwendungen. Voraussetzung bleibt die nachgewiesene Kompatibilität des tatsächlich eingesetzten Themes, der Plugins, der Importer und aller eigenen Datenbankzugriffe.

Bei verteilten Deployments, mehreren Webservern oder zeitlich geballten Schreibvorgängen bleiben MySQL oder MariaDB die passendere Datenbankstrategie. Das betrifft insbesondere Shops mit Bestellungen, Buchungs- und Ticketing-Systeme, Community-Funktionen und automatisierte Schnittstellen mit vielen schreibenden Requests. Maßgeblich ist nicht eine pauschale Besucherzahl, sondern ob unabhängige Prozesse gleichzeitig dieselbe Datenbasis ändern müssen. Für direkten gleichzeitigen Datenbankzugriff mehrerer Hosts über ein Netzwerk empfiehlt SQLite grundsätzlich ein Client-Server-System.

Für eine bestehende Website ist ein Plattformwechsel zudem nicht automatisch ein Performance-Projekt. Objekt- oder seitenbezogenes Caching kann Datenbankabfragen und PHP-Arbeit verringern, ohne MySQL oder MariaDB zu ersetzen. Caching und SQLite lösen damit unterschiedliche Aufgaben: Ersteres reduziert wiederkehrende Verarbeitung, Letzteres verändert Speicher- und Betriebsmodell der Datenbank. Die offiziellen WordPress-Anforderungen nennen weiterhin MariaDB oder MySQL als reguläre Datenbankvoraussetzungen.

Vor der Freigabe sollte eine Go-/No-Go-Prüfung mindestens diese Punkte abdecken:

• Architektur: Läuft WordPress dauerhaft auf einem einzelnen Server, ohne dass mehrere Hosts dieselbe SQLite-Datei direkt über ein Netzwerkdateisystem öffnen müssen?
• Schreibmuster: Sind parallele Bestellungen, Buchungen, Formulare, REST- oder AJAX-Schreibvorgänge begrenzt und in einer getrennten Umgebung geprüft?
• Kompatibilität: Funktionieren Theme, Plugins, MU-Plugins und eigene SQL-Abfragen in der Testinstanz?
• Drop-ins: Ist wp-content/db.php frei von Konflikten mit Datenbank- oder Caching-Lösungen?
• Migration: Ist klar dokumentiert, dass die Aktivierung keine Inhalte aus MySQL oder MariaDB übernimmt?
• Laufzeit: Erfüllt die von PHP geladene SQLite-Bibliothek die Plugin-Mindestversion, und sind PHP-, SQLite- sowie Plugin-Updates in den Wartungsprozess eingebunden?
• Sicherung: Ermittelt das Backup den aktuellen DB_PATH, unterstützt es den verwendeten Journalmodus, und wurde eine Wiederherstellung in einer getrennten Umgebung durchgeführt und dokumentiert?
• Betrieb: Sind Updates des Plugins und von WordPress mit einem wiederholbaren Testablauf abgesichert?