SQLite als WordPress-database: stand van zaken, beperkingen en toepassingen

WordPress en SQLite op de juiste manier inperken

WordPress ondersteunt SQLite momenteel niet als standaard selecteerbaar databaseplatform in de kern. In de officiële systeemvereisten wordt nog steeds MySQL of MariaDB genoemd; SQLite behoort niet tot de standaardvereisten voor een WordPress-installatie. Wie WordPress met SQLite gebruikt, verandert daarom niet simpelweg een instelling in de kern, maar voegt een eigen integratielaag toe aan WordPress.

Deze laag vormt de plug-in Integratie van SQLite-databases Klaar. Het is beschikbaar in de WordPress.org-pluginbibliotheek en wordt ontwikkeld als community- of feature-plugin. Het doel is om een SQLite-implementatie te testen en feedback te verzamelen met het oog op een mogelijke latere integratie in de kern. De aanwezigheid in het WordPress.org-ecosysteem betekent dus niet dat het een vast onderdeel van een normale WordPress-installatie is.

Het initiatief heeft een langere aanloop: in september 2022 werd binnen het WordPress-Core-team publiekelijk voorgesteld om SQLite op de lange termijn officieel te ondersteunen. Sinds januari 2023 is de implementatie beschikbaar als zelfstandige plug-in; de toenmalige koppeling met Performance Lab beschrijft een ontwikkelingsstap, niet de huidige standaardaanpak voor elke WordPress-website.

Voor een betrouwbare indeling is de versienummering bepalend. Op het moment van onderzoek, 18 oktober 2026, is v3.1.0 van 8 oktober 2026 de stabiele releaseversie. Uitspraken uit de ontwikkelingstak mogen niet zomaar worden beschouwd als kenmerken van deze stabiele versie. Omgekeerd zou het onjuist zijn om de actieve plug-in louter daarom gelijk te stellen aan een algemene productieve vrijgave voor elk WordPress-toepassingsgeval.

De vraag van de lezer kan daarom slechts gedeeltelijk met ja worden beantwoord: SQLite kan zinvol zijn voor duidelijk afgebakende installaties, bijvoorbeeld voor ontwikkeling, demo’s of kleine websites op één server met overzichtelijke wijzigingen. Voor gedistribueerde, schrijfintensieve of bedrijfskritische installaties blijven MySQL of MariaDB de standaard ondersteunde en doorgaans geschiktere basis. Doorslaggevend zijn de architectuur, de schrijfpatronen en de daadwerkelijke compatibiliteit van de gebruikte stack.

Bestandsdatabase, drop-in en SQL-compatibiliteit

Het fundamentele verschil zit hem in het opslagmodel. SQLite is een Bestandsdatabase: De gegevens worden lokaal opgeslagen in een databasebestand op het bestandssysteem. MySQL en MariaDB werken daarentegen als zelfstandige databaseservices waarmee WordPress via een serververbinding communiceert. SQLite kan daarom een slankere omgeving mogelijk maken, maar vereist wel een geschikte lokale opslaglocatie en de juiste bestandsrechten.

WordPress-Core, thema’s en de meeste uitbreidingen maken voor databasetoegang gebruik van de bekende interface wpdb. De plug-in vervangt de gebruikelijke databaselaag via de drop-in wp-content/db.php. Deze drop-in vangt de query's op en fungeert als tussenlaag tussen de verwachte MySQL-georiënteerde WordPress-omgeving en SQLite. Hierdoor blijft de gebruikersinterface voor veel componenten hetzelfde, ook al verandert de database-infrastructuur.

De bemiddelingslaag is het cruciale punt achter de beknopte uitspraak „WordPress draait op SQLite“. WordPress genereert niet automatisch SQLite-specifieke SQL. De projectdocumentatie in de ontwikkelingsbranch trunk beschrijft een MySQL-parser die de SQL-grammatica en de benodigde functies voor SQLite nabootst. Dit geeft uitleg over de ontwikkelingsaanpak, maar is noch een toezegging voor een stabiele versie, noch een garantie dat elke afzonderlijke MySQL-query of -uitbreiding zonder aanpassingen compatibel is.

Je moet vooral uitbreidingen zorgvuldig controleren die rechtstreeks SQL genereren, databasefuncties vereisen of eigen tabellen op een ongebruikelijke manier beheren. Dit geldt ook voor importtools, rapportagetools en onderhoudscripts. Een thema of plug-in kan in de standaardmodus goed werken, maar toch mislukken bij een zeldzame beheertaak, een update of een specifieke query vanwege een niet-gedocumenteerde eigenaardigheid van MySQL.

De verschillen in schema, metadata en typische zoekopdrachten blijven relevant voor de beoordeling. Het interne overzicht van WordPress-databasetabellen en hun prestaties helpt bij het identificeren van database-intensieve uitbreidingen en eigen tabellen als mogelijke controlepunten. SQLite-integratie Dit is geen vervanging voor een analyse van dergelijke zoekopdrachten, noch voor de verantwoordelijkheid om aanpassingen buiten de standaardinterface van WordPress vóór gebruik te testen.

Wanneer SQLite technisch gezien een haalbare optie is

Een verstandige beslissing kan niet worden gebaseerd op een algemeen bezoekersaantal. Bepalend is de Schrijfwedstrijd: SQLite staat meerdere gelijktijdige lezers toe, maar per databasebestand kan er slechts één schrijfbewerking tegelijk plaatsvinden. Als wijzigingen in de tijd samenvallen, moeten verdere schrijfbewerkingen wachten. De SQLite-documentatie adviseert bij veel onafhankelijke clients, meerdere computers of veel gelijktijdige schrijfbewerkingen om een client-server-database te gebruiken.

Duidelijk af te bakenen toepassingsgebieden zijn lokale ontwikkeling, trainingen, demo’s en kortstondige testomgevingen. Daar is het niet nodig om een aparte MySQL- of MariaDB-service in te stellen, terwijl de plug-ins en thema’s op een gecontroleerde manier kunnen worden getest. Ook een kleine website op één enkele server kan geschikt zijn, mits deze voornamelijk wordt gelezen en redactionele wijzigingen zelden plaatsvinden en niet in korte tijd achter elkaar.

Een strakke bedrijfswebsite, een persoonlijke blog of een campagnepagina zijn echter niet automatisch geschikt. Contactformulieren, ledengedeelten, nieuwsbriefintegraties of individueel geprogrammeerde eindpunten kunnen extra schrijfbewerkingen activeren. Controleer daarom niet alleen het aantal paginaweergaven, maar ook het bijwerken van opties, ingevulde formulieren, geplande taken en gegevenswijzigingen door plug-ins en externe interfaces.

Voor webwinkels met bestellingen, boekings- en ticketingsystemen, actieve communities of toepassingen met veel AJAX- en REST-schrijfbewerkingen is deze beperking meestal van groter belang. Daar kunnen meerdere gebruikers vrijwel tegelijkertijd bestellingen opslaan, beschikbaarheden wijzigen of berichten plaatsen. Meerdere webservers achter een load balancer passen eveneens niet bij de lokale bestandsaanpak die SQLite voor dit gebruiksscenario vereist.

Caching vervult een andere functie dan SQLite. Pagina- of objectcaching kan terugkerende leesbewerkingen en daarmee databasequery’s verminderen; het maakt een schrijfintensieve toepassing echter niet tot een conflictarme SQLite-installatie. Omgekeerd vervangt SQLite geen cacheconcept. Voor bestaande websites kan het daarom de veiligere keuze zijn om MySQL of MariaDB te behouden in combinatie met geschikte caching, zonder van databaseplatform te wisselen.

Scenario's systematisch evalueren met SQLite

Of SQLite geschikt is voor WordPress, hangt niet af van het aantal bezoekers, maar van de combinatie van schrijfbewerkingen, de serverconfiguratie en uitbreidingen. SQLite kan gelijktijdige leesverzoeken verwerken, maar schrijfbewerkingen op hetzelfde databasebestand niet willekeurig parallel uitvoeren. Daarom is een enkele website met veel paginaweergaven niet automatisch ongeschikt, terwijl gelijktijdig geplaatste bestellingen of boekingen wel kritiek kunnen zijn.

De tabel is een voorselectie, geen definitieve goedkeuring. Vooral bij een kleine bedrijfswebsite kunnen een CRM-formulier, een ledengedeelte of een externe automatiseringsdienst ervoor zorgen dat een pagina waarop zelden wordt geschreven, een zware schrijfbelasting vormt. Omgekeerd blijft een blog met veel lezers een plausibele kandidaat, mits reacties, formulieren en administratieve wijzigingen overzichtelijk blijven. De plug-in wijst er zelf op dat de geschiktheid afhangt van het verkeer en de schrijfbelasting.

Multisite wordt in de projectdocumentatie van de ontwikkelingsbranch beschreven als een scenario dat kan worden geïmplementeerd; bovendien bevat de repository hiervoor eigen tests. Hieruit volgt echter geen algemene goedkeuring voor gebruik in productieomgevingen voor grote netwerken met veel redacteuren, sites of integraties. Behandel een netwerk daarom als een op zichzelf staand compatibiliteitsgeval en controleer de daadwerkelijk gebruikte beheer-, update- en inhoudsprocessen.

De verplichte praktijkstap is het testen van de concrete stack in een afzonderlijke omgeving. Hieronder vallen het actieve thema, alle productieve plug-ins, individuele MU-plug-ins, importtools, formulieren, REST-eindpunten en tools voor back-ups en monitoring. Het is niet alleen van cruciaal belang of pagina’s laden: elke uitbreiding met eigen SQL-aannames of frequente wijzigingen moet de SQLite-laag betrouwbaar doorlopen.

Installatie en veilige padconfiguratie

De instelling is geschikt voor een nieuwe testinstallatie of een bewust geplande SQLite-installatie, maar niet als snelle oplossing voor een bestaande productieomgeving. Voordat de extensie wordt geactiveerd, moet PHP de extensie pdo_sqlite inclusief PDO-ondersteuning; bovendien vereist de plug-in SQLite vanaf versie 3.37.0. PHP heeft schrijfrechten nodig voor de gekozen databasemap. Het installatievenster controleert deze voorwaarden en detecteert bovendien bestaande, conflicterende database-drop-ins.

De opgegeven minimumversie van SQLite is een technische vereiste voor de plug-in, maar geen algemene garantie voor elk productief gebruiksscenario. Sinds plug-inversie 3.0 is Write-Ahead Logging standaard ingeschakeld. Beheerders moeten daarom controleren welke SQLite-bibliotheek de gebruikte PHP-runtime daadwerkelijk laadt, en updates van plug-ins, PHP en SQLite meenemen in hun onderhouds- en compatibiliteitscontroles.

Let vooral op wp-content/db.php. Dit bestand is de centrale WordPress-drop-in voor de databaselaag; twee oplossingen kunnen dit niet tegelijkertijd gebruiken. Als er daar al een drop-in bestaat, bijvoorbeeld voor een andere databaseverbinding of een cachingoplossing, moet vóór de installatie worden nagegaan welke component deze biedt en of een nette verwijdering mogelijk is.

De stabiele versie 3.1.0 gebruikt standaard willekeurig benoemde submappen onder wp-content/database/. De vastgestelde opslaglocatie wordt weergegeven in db-path.php vastgelegd en via DB_PATH beschikbaar gesteld. Back-up- en migratietools mogen daarom niet uitgaan van historische bestandsnamen of een willekeurig standaardpad. De vroegere constanten DB_DIR en DB_FILE zijn in 3.1 als verouderd gemarkeerd; DB_PATH heeft voorrang.

Voor een geplande nieuwe installatie raadt het project een absoluut pad aan buiten de openbaar toegankelijke webmap. De doelmap moet schrijfbaar zijn voor het PHP-proces. De volgende instelling hoort thuis in wp-config.php en is een configuratievoorbeeld, geen instructie voor het achteraf aanpassen van een bestaande website.

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

Waarschuwing: Een nieuw ingestelde DB_PATH verplaatst geen bestaand databasebestand. Het kiest een andere opslaglocatie. Als de waarde zonder voorbereiding wordt gewijzigd, kan WordPress daarom een andere of lege database gebruiken. Bepaal vooraf gezamenlijk het pad, de toegangsrechten, de back-up en voer een hersteltest uit voordat je het in productie neemt.

De willekeurige mappenstructuur in versie 3.1 vermindert alleen de voorspelbaarheid van het standaardpad. Deze vervangt noch de rechten van het bestandssysteem, noch een opslaglocatie die betrouwbaar is beveiligd tegen openbare blootstelling. Het veiligst is het aanbevolen pad buiten de webroot; als er voor een andere opslaglocatie wordt gekozen, moet de toegang daartoe door de webserver eveneens op betrouwbare wijze worden uitgesloten.

Geen databasewisseling via activering

Bij een bestaande WordPress-website met MySQL of MariaDB is het inschakelen van SQLite Database Integration geen migratie. De plug-in maakt een aparte, aanvankelijk lege SQLite-database aan. Berichten, gebruikers, instellingen, mediabestanden en plug-ingegevens uit de bestaande database worden niet automatisch overgenomen. Als de integratie later wordt uitgeschakeld, maakt WordPress weer verbinding met de bestaande database; wijzigingen die in SQLite zijn aangebracht, worden niet teruggedraaid.

Deze scheiding is handig voor tests, maar essentieel voor productieve migraties. Wie daadwerkelijk inhoud naar een ander databaseplatform wil overzetten, heeft een eigen, traceerbaar migratieplan nodig, inclusief gegevensoverdracht, controle van tekensets en opties, en een terugvalplan. Het louter omschakelen van de drop-in kan dit proces niet vervangen.

De benaming afzonderlijke gegevensbestanden Dit moet letterlijk worden opgevat: tijdens het gebruik van SQLite kunnen beide databases verschillende inhoud bevatten. Een testbericht in SQLite verschijnt na het uitschakelen niet plotseling in MySQL of MariaDB. Evenzo blijft een nieuw MySQL-bericht onzichtbaar zolang WordPress het SQLite-bestand als actieve gegevensbron gebruikt.

De repository wp-sqlite-db beschrijft zichzelf als een op zichzelf staand project met een afzonderlijke SQLite-drop-in en verwijst naar de oorspronkelijke SQLite-integratie. Het is daarom niet gelijk te stellen aan de huidige WordPress-repository. Bestanden, configuratiewaarden en handleidingen uit dit project mogen niet worden overgenomen in de huidige SQLite-database-integratie; de documentatie van het daadwerkelijk gebruikte project is in elk geval doorslaggevend.

Voor bestaande websites is het vaak de veiligere keuze om MySQL of MariaDB te behouden en knelpunten afzonderlijk te onderzoeken. Pagina- of objectcaching kan het aantal databasequery’s verminderen, maar is geen vervanging voor gegevensmigratie en lost geen compatibiliteitsproblemen met de SQLite-integratie op. Dit overzicht helpt bij het in kaart brengen van typische WordPress-query's en cachingbenaderingen: WordPress-prestaties en cachingoptimalisatie.

SQLite-database beveiligen en consistent back-uppen

Bij SQLite staat de WordPress-database in één bestand op de server. Dit bestand kan onder andere inhoud, gebruikersaccounts, opties en configuratiegegevens bevatten en moet daarom net als een databaseserver worden beveiligd. Een willekeurig benoemde standaard-submap die versie 3.1 gebruikt, maakt het alleen maar moeilijker om een pad te raden; het is geen vervanging voor correct ingestelde bestandsrechten en toegangsbeperkingen van de webserver.

Het project beveelt aan om, DB_PATH als absoluut pad buiten de webroot instellen. PHP heeft daar schrijfrechten nodig, terwijl de webserver het databasebestand niet rechtstreeks mag verstrekken. Deze scheiding vermindert het risico dat een verkeerde configuratie binnen de openbaar toegankelijke map het bestand toegankelijk maakt. Bij de implementatie, het rechtenbeheer en het maken van back-ups moet uitdrukkelijk rekening worden gehouden met de gekozen opslaglocatie.

Voor back-ups is het sinds de 3.1-reeks van cruciaal belang om geen historische bestandsnaam en geen willekeurig standaardpad vast in te stellen. De plug-in kan het daadwerkelijke pad via DB_PATH tijdens de uitvoering beschikbaar maken; back-up-, migratie- en hersteltools moeten deze daarom na het laden van WordPress vaststellen. Voordat je het systeem vrijgeeft, moet je het herstel in een aparte omgeving uitvoeren en het daarvoor benodigde pad, de configuratie en de stappen documenteren.

Vanaf pluginversie 3.0 maakt de integratie standaard gebruik van de WAL-modus. Daarbij kunnen naast de hoofddatabase ook bijbehorende bestanden met de extensies -wal en -shm ontstaan. Controleer daarom uitdrukkelijk of de gebruikte back-upsoftware de WAL-werking van de actieve SQLite-database ondersteunt en rekening houdt met deze onderdelen. Zonder een dergelijke goedkeuring van de software kan er geen consistente back-up worden gemaakt door het hoofdbestand simpelweg te kopiëren.

De door de plug-in genoemde minimumversie SQLite 3.37.0 geeft de technische ondergrens van de integratie aan. Voor een goede werking moet je bovendien in de gaten houden welke SQLite-versie PHP daadwerkelijk gebruikt, en beveiligings- en foutcorrecties van de gebruikte PHP- en SQLite-pakketten opnemen in het reguliere updateproces. Zonder een geschikte bron in de bestaande bronnenlijst kan hieruit echter geen betrouwbaar advies worden afgeleid voor afzonderlijke hogere SQLite-versies of bepaalde backports.

Export- en back-uptools moeten niet alleen worden gebruikt omdat ze bekend zijn uit MySQL- of MariaDB-installaties. Controleer voor de betreffende tool of deze de SQLite-database in de huidige DB_PATH en wordt ondersteund in de geconfigureerde logboekmodus. Voer vervolgens een herstel uit in de daarvoor bestemde hostingomgeving en leg vast of het databasepad, de benodigde databaseonderdelen en de WordPress-configuratie volledig zijn samengevoegd.

Conflicten herkennen en gericht onderzoeken

De migratie hoort in eerste instantie thuis in een staging- of testomgeving, niet in de eerste productieve uitrol. Registreer vóór de installatie de bestaande bestanden onder wp-content/db.php evenals plug-ins, MU-plug-ins en aangepaste uitbreidingen die rechtstreeks gebruikmaken van MySQL. Een tweede drop-in-database kan niet parallel werken; tijdens het installatieproces van de integratie wordt daarom gecontroleerd of er dergelijke conflicten zijn.

Controleer daarna concrete processen in plaats van alleen de startpagina: aanmelding en beheer, het aanmaken van inhoud, zoeken, formulieren, geplande taken, importeren en exporteren, evenals back-ups en herstel. Herhaal de tests na updates van plug-ins en WordPress. De integratielaag verwerkt MySQL-syntaxis voor SQLite, maar de ondersteuning die in het project wordt beschreven, is geen vervanging voor het controleren van eigen query's of zeldzame functies van een uitbreiding.

Veelvoorkomende fouten bij het inrichten zijn het ontbreken van pdo_sqlite respectievelijk pdo of onvoldoende schrijfrechten voor de databasemap. Even problematisch is de veronderstelling dat de activering de inhoud van een bestaande MySQL- of MariaDB-installatie overneemt: er wordt een afzonderlijke SQLite-database aangemaakt, er vindt niet automatisch een gegevensmigratie plaats. Ook een nieuwe DB_PATH verplaatst geen bestaand bestand, maar verwijst naar een andere locatie.

Als er onder belasting wachttijden optreden, ga dan eerst na welke acties gelijktijdig schrijven: bijvoorbeeld bestellingen, formulierverwerking, REST-verzoeken of achtergrondtaken. SQLite staat meerdere lezers toe, maar serialiseert schrijfbewerkingen per databasebestand; meerdere webservers stellen bovendien hogere eisen aan de database-architectuur. Dit is niet te vergelijken met de vergrendelingsmechanismen van MySQL-InnoDB. Voor het analyseren van de oorzaken bij traditionele WordPress-databases biedt het artikel over gelijktijdige databasetoegangen en vergrendelingen.

De juiste databasestrategie kiezen

SQLite is een acceptabele keuze voor WordPress als de website op één enkel systeem draait, voornamelijk wordt gelezen en het aantal gelijktijdige wijzigingen beperkt en bekend is. Dit is meer geschikt voor lokale ontwikkeling, demo’s of kleine redactionele websites dan voor toepassingen met veel transacties. Voorwaarde blijft dat de daadwerkelijk gebruikte thema’s, plug-ins, importtools en alle eigen databasetoegangen aantoonbaar compatibel zijn.

Bij gedistribueerde implementaties, meerdere webservers of een concentratie van schrijfbewerkingen in een korte tijd blijven MySQL of MariaDB de meest geschikte databasestrategie. Dit geldt met name voor webwinkels met bestellingen, boekings- en ticketingsystemen, communityfuncties en geautomatiseerde koppelingen met veel schrijfverzoeken. Niet het totale aantal bezoekers is bepalend, maar of onafhankelijke processen tegelijkertijd dezelfde database moeten wijzigen. Voor directe, gelijktijdige databasetoegang door meerdere hosts via een netwerk beveelt SQLite in principe een client-server-systeem aan.

Voor een bestaande website is een platformwissel bovendien niet automatisch een prestatieverbeteringsproject. Object- of paginagerichte caching kan het aantal databasequery’s en de PHP-belasting verminderen, zonder MySQL of MariaDB te vervangen. Caching en SQLite vervullen dus verschillende taken: het eerste vermindert terugkerende verwerking, het laatste verandert het opslag- en bedrijfsmodel van de database. In de officiële WordPress-vereisten worden MariaDB of MySQL nog steeds genoemd als standaarddatabasevereisten.

Voorafgaand aan de goedkeuring moet een go/no-go-controle ten minste de volgende punten omvatten:

• Architectuur: Draait WordPress continu op één enkele server, zonder dat meerdere hosts hetzelfde SQLite-bestand rechtstreeks via een netwerkbestandssysteem hoeven te openen?
• Schrijfpatronen: Worden gelijktijdige bestellingen, boekingen, formulieren, REST- of AJAX-schrijfbewerkingen beperkt en in een afzonderlijke omgeving getest?
• Compatibiliteit: werken het thema, de plug-ins, de MU-plug-ins en eigen SQL-query's in de testomgeving?
• Drop-ins: Is wp-content/db.php vrij van conflicten met database- of cachingoplossingen?
• Migratie: Is duidelijk gedocumenteerd dat bij de activering geen gegevens uit MySQL of MariaDB worden overgenomen?
• Looptijd: Voldoet de door PHP geladen SQLite-bibliotheek aan de minimumversievereisten voor de plug-in, en zijn updates van PHP, SQLite en de plug-in opgenomen in het onderhoudsproces?
• Back-up: Bepaalt de back-up het huidige DB_PATH, ondersteunt deze de gebruikte journaalmodus en is er een herstel uitgevoerd en gedocumenteerd in een afzonderlijke omgeving?
• Bedrijf: Wordt het bijwerken van de plug-in en van WordPress ondersteund door een herhaalbare testprocedure?