SQLite som WordPress-databas: utvecklingsstatus, begränsningar och användningsområden

Att placera WordPress och SQLite på rätt plats

WordPress stöder för närvarande inte SQLite som en vanlig databasplattform som kan väljas i kärnan. De officiella systemkraven anger fortfarande MySQL eller MariaDB; SQLite ingår inte i standardkraven för en WordPress-installation. Den som använder WordPress med SQLite ändrar därför inte bara en inställning i kärnan, utan kompletterar WordPress med ett eget integrationslager.

Det här lagret tillhandahåller plugin-modulen Integration med SQLite-databasen Klar. Den finns tillgänglig i WordPress.org:s plugin-katalog och utvecklas som ett community- respektive feature-plugin. Syftet är att testa en SQLite-implementering och samla in feedback inför en eventuell senare integration i kärnan. Att det finns i WordPress.org-ekosystemet innebär alltså inte att det är godkänt som en fast del av en vanlig WordPress-installation.

Initiativet har en längre förhistoria: I september 2022 lades ett offentligt förslag fram i WordPress-kärnteamet om att på sikt införa officiellt stöd för SQLite. Sedan januari 2023 kan implementeringen hämtas som ett fristående plugin; den dåvarande kopplingen till Performance Lab beskriver ett utvecklingssteg, inte den nuvarande standardvägen för varje WordPress-webbplats.

För en tillförlitlig klassificering är versionsnumret avgörande. Vid tidpunkten för undersökningen, den 18 oktober 2026, är v3.1.0 från den 8 oktober 2026 den stabila releaseversionen. Uttalanden från utvecklingsgrenen får inte utan vidare betraktas som egenskaper hos denna stabila version. Omvänt skulle det vara felaktigt att enbart på grund av detta likställa det aktiva tillägget med en allmän produktionsgodkännande för alla användningsfall inom WordPress.

Läsarfrågan kan därför endast besvaras med ett ”ja” i viss utsträckning: SQLite kan vara ett lämpligt val för tydligt avgränsade installationer, till exempel för utveckling, demonstrationer eller små webbplatser med en enda server och överskådliga ändringar. För distribuerade, skrivintensiva eller affärskritiska installationer förblir MySQL eller MariaDB den normalt stödda och oftast lämpligare grunden. Avgörande faktorer är arkitekturen, skrivmönstren och den faktiska kompatibiliteten hos den använda stacken.

Fildatabas, drop-in och SQL-kompatibilitet

Den grundläggande skillnaden ligger i lagringsmodellen. SQLite är en Fildatabas: Uppgifterna lagras lokalt i en databasfil på filsystemet. MySQL och MariaDB fungerar däremot som fristående databastjänster, med vilka WordPress kommunicerar via en serveranslutning. SQLite kan därför möjliggöra en smidigare miljö, men kräver en lämplig lokal lagringsplats och rätt filbehörigheter.

WordPress-kärnan, teman och de flesta tillägg använder det välkända gränssnittet för databasåtkomst wpdb. Pluginet ersätter det vanliga databaslagret via drop-in-funktionen wp-content/db.php. Denna drop-in fångar upp frågorna och fungerar som en mellanhand mellan den förväntade MySQL-baserade WordPress-miljön och SQLite. På så sätt förblir användargränssnittet detsamma för många komponenter, trots att databasunderlaget ändras.

Mellanlagret är den avgörande faktorn bakom det förenklade påståendet „WordPress körs på SQLite“. WordPress genererar inte automatiskt SQL-kod som är specifik för SQLite. Projektdokumentationen i utvecklingsgrenen trunk beskriver en MySQL-parser som efterliknar SQL-grammatiken och de funktioner som krävs för SQLite. Detta förklarar utvecklingsstrategin, men utgör varken ett löfte om en stabil version eller en garanti för att varje enskild MySQL-fråga eller -utvidgning är kompatibel utan anpassning.

Du bör vara särskilt noggrann när du granskar tillägg som genererar SQL direkt, kräver databasfunktioner eller hanterar egna tabeller på ett ovanligt sätt. Detta gäller även importverktyg, rapporteringsverktyg och underhållsskript. Ett tema eller plugin kan fungera under normala förhållanden, men ändå misslyckas vid en sällsynt administratörshandling, en uppdatering eller en speciell sökning på grund av en MySQL-egenskap som inte stöds.

Skillnaderna i schema, metadata och typiska sökfrågor är fortfarande relevanta för utvärderingen. Den interna översikten över WordPress-databastabeller och deras prestanda hjälper till att identifiera databasintensiva tillägg och egna tabeller som möjliga kontrollpunkter. SQLite-integration ersätter varken en analys av sådana sökfrågor eller ansvaret att testa anpassningar utanför WordPress standardgränssnitt innan de tas i bruk.

När SQLite är tekniskt försvarbart

Ett välgrundat beslut baseras inte på ett generellt besökarantal. Det avgörande är Skrivtävling: SQLite tillåter flera parallella läsare, men endast en skrivoperation kan utföras åt gången per databasfil. Om ändringar sker samtidigt måste ytterligare skrivoperationer vänta. SQLite-dokumentationen rekommenderar en klient-server-databas vid många oberoende klienter, flera datorer eller många samtidiga skrivoperationer.

Tydligt avgränsade användningsområden är lokal utveckling, utbildningar, demonstrationer och kortvariga testmiljöer. Där behövs ingen separat MySQL- eller MariaDB-tjänst, samtidigt som plugin- och temastacken kan testas på ett kontrollerat sätt. Även en liten webbplats på en enskild server kan vara lämplig, om den främst används för läsning och redaktionella ändringar sker sällan och inte koncentreras till en viss tidsperiod.

En enkel företagswebbplats, en personlig blogg eller en kampanjsida är dock inte automatiskt lämpliga. Kontaktformulär, medlemsområden, nyhetsbrevsintegrationer eller individuellt programmerade slutpunkter kan utlösa ytterligare skrivoperationer. Kontrollera därför inte bara sidvisningar, utan även uppdateringar av inställningar, formulärinmatningar, schemalagda uppgifter samt dataändringar via plugins och externa gränssnitt.

För webbutiker med beställningar, boknings- och biljettsystem, aktiva communityn eller applikationer med många AJAX- och REST-skrivoperationer är begränsningen oftast mer betydande. Där kan flera användare nästan samtidigt spara beställningar, ändra tillgänglighet eller skapa inlägg. Flera webbservrar bakom en lastbalanserare passar inte heller in i den lokala filstrategi som SQLite förutsätter för detta användningsfall.

Caching fyller en annan funktion än SQLite. Sid- eller objektcaching kan minska återkommande läsåtkomst och därmed databasfrågor; det gör dock inte en skrivintensiv applikation till en SQLite-installation med få konflikter. Omvänt ersätter SQLite inte ett cachekoncept. För befintliga webbplatser kan det därför vara den säkrare vägen att behålla MySQL eller MariaDB tillsammans med lämplig caching, utan att byta databasplattform.

Systematisk utvärdering av scenarier med SQLite

Det är inte antalet besökare som avgör om SQLite passar för WordPress, utan samspelet mellan skrivoperationer, serverkonfiguration och tillägg. SQLite kan hantera parallella läsåtkomster, men kan inte utföra skrivoperationer på samma databasfil parallellt i obegränsad utsträckning. Därför är en enskild webbplats med många sidvisningar inte automatiskt olämplig, medan beställningar eller bokningar som utlöses samtidigt kan vara kritiska.

Tabellen är en preliminär urval, inte ett godkännande. Särskilt för en liten företagswebbplats kan ett CRM-formulär, ett medlemsområde eller en extern automatiseringstjänst förvandla en sida med få inlägg till en stor skrivbelastning. Å andra sidan förblir en blogg med många läsare en rimlig kandidat om kommentarer, formulär och administrativa ändringar är hanterbara. Pluginet påpekar själv att lämpligheten beror på trafik och skrivbelastning.

Multisite beskrivs i projektdokumentationen för utvecklingsgrenen som ett scenario som går att konfigurera; dessutom innehåller repositoriet egna tester för detta. Detta innebär dock inte att det finns något allmänt godkännande för produktion i stora nätverk med många redaktörer, webbplatser eller integrationer. Behandla därför ett nätverk som ett fristående kompatibilitetsfall och kontrollera de faktiska arbetsflödena för administration, uppdatering och innehåll.

Det obligatoriska praktiska steget är att testa den konkreta stacken i en separat miljö. Detta omfattar det aktiva temat, alla produktiva plugins, anpassade MU-plugins, importverktyg, formulär, REST-ändpunkter samt verktyg för säkerhetskopiering och övervakning. Det avgörande är inte bara om sidorna laddas: varje tillägg med egna SQL-antaganden eller frekventa ändringar måste på ett tillförlitligt sätt passera genom SQLite-lagret.

Installation och säker konfiguration av sökvägar

Verktyget är lämpligt för en ny testinstallation eller en noggrant planerad SQLite-installation, men inte som en snabblösning för en befintlig produktionsmiljö. Innan aktiveringen måste PHP ha tillägget pdo_sqlite tillsammans med stöd för PDO; dessutom kräver tillägget SQLite version 3.37.0 eller senare. PHP behöver skrivrättigheter för den valda databaskatalogen. Konfigurationsdialogen kontrollerar dessa villkor och upptäcker dessutom befintliga databas-drop-ins som kan orsaka konflikter.

Den angivna lägsta versionen av SQLite är ett tekniskt krav för plugin-modulen, men ingen generell garanti för alla produktiva användningsfall. Sedan plugin-version 3.0 är Write-Ahead Logging aktiverat som standard. Administratörer bör därför kontrollera vilket SQLite-bibliotek som den använda PHP-körmiljön faktiskt laddar, och inkludera uppdateringar av plugins, PHP och SQLite i sina underhålls- och kompatibilitetskontroller.

Kontrollera särskilt wp-content/db.php. Denna fil är det centrala WordPress-drop-in-pluginet för databaslagret; två lösningar kan inte använda den samtidigt. Om det redan finns ett drop-in där, till exempel för en annan databasanslutning eller en cachelösning, måste man innan installationen klargöra vilken komponent det tillhandahåller och om en smidig avinstallation är möjlig.

I standardinställningarna använder den stabila versionen 3.1.0 slumpmässigt namngivna underkataloger under wp-content/database/. Den fastställda lagringsplatsen anges i db-path.php antecknats och via DB_PATH tillhandahålls. Verktyg för säkerhetskopiering och migrering får därför inte förutsätta några historiska filnamn eller en förutbestämd standardväg. De tidigare konstanterna DB_DIR och DB_FILE är markerade som föråldrade i 3.1; DB_PATH har företräde.

För en planerad nyinstallation rekommenderar projektet en absolut sökväg utanför den offentligt tillgängliga webbkatalogen. Målkatalogen måste vara skrivbar för PHP-processen. Följande inställning ska placeras i wp-config.php och är ett konfigurations exempel, inte en anvisning för att i efterhand ändra en webbplats som redan är i drift.

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

Varning: En nyligen inställd DB_PATH flyttar inte någon befintlig databasfil. Den väljer istället en annan lagringsplats. Om värdet ändras utan förvarning kan WordPress därför komma att använda en annan databas eller en tom databas. Planera gemensamt sökvägen, åtkomsträttigheterna, säkerhetskopieringen och ett återställningstest innan ni går live.

Den slumpmässiga katalogstrukturen i version 3.1 minskar endast förutsägbarheten hos standardvägen. Den ersätter varken filsystemrättigheter eller en lagringsplats som är tillförlitligt skyddad mot offentlig spridning. Det säkraste alternativet är den rekommenderade sökvägen utanför webbroten; om en annan lagringsplats väljs måste webbserverns åtkomst till den uteslutas på ett lika tillförlitligt sätt.

Inget databasbyte genom aktivering

För en befintlig WordPress-webbplats med MySQL eller MariaDB innebär aktivering av SQLite Database Integration ingen migrering. Pluginet skapar en separat, till en början tom SQLite-databas. Inlägg, användare, inställningar, mediefiler och plugin-data från den tidigare databasen överförs inte automatiskt. Om integrationen senare inaktiveras ansluter WordPress återigen till den tidigare databasen; ändringar som gjorts i SQLite överförs inte tillbaka.

Denna åtskillnad är användbar vid tester, men avgörande vid produktiva övergångar. Den som verkligen vill överföra innehåll till en annan databasplattform behöver en egen, överskådlig migreringsplan som omfattar dataöverföring, kontroll av teckenuppsättningar och inställningar samt en återgångsplan. Att bara byta drop-in kan inte ersätta denna process.

Beteckningen separata datamängder Detta ska förstås bokstavligt: Under drift med SQLite kan de båda databaserna innehålla olika data. Ett testinlägg i SQLite dyker inte plötsligt upp i MySQL eller MariaDB efter att SQLite har inaktiverats. På samma sätt förblir ett nytt MySQL-inlägg osynligt så länge WordPress använder SQLite-filen som aktiv datakälla.

Repositoriet wp-sqlite-db beskriver sig själv som ett fristående projekt med en enskild SQLite-drop-in och hänvisar till den ursprungliga SQLite-integrationen. Det ska därför inte likställas med det aktuella WordPress-repositoriet. Filer, konfigurationsvärden och instruktioner från detta projekt bör inte överföras till den aktuella SQLite Database Integration; det är alltid dokumentationen för det specifika projektet som gäller.

För befintliga webbplatser är det ofta det säkrare valet att behålla MySQL eller MariaDB och undersöka flaskhalsar separat. Sid- eller objektcaching kan minska antalet databasfrågor, men ersätter inte datamigrering och löser inte kompatibilitetsproblemen med SQLite-integrationen. Denna översikt hjälper till att klassificera typiska WordPress-frågor och cachelösningar: WordPress-prestanda och optimering av cachelagring.

Skydda och säkerhetskopiera SQLite-databasen på ett konsekvent sätt

I SQLite lagras WordPress-databasen i en fil på servern. Den kan bland annat innehålla innehåll, användarkonton, inställningar och konfigurationsdata och måste därför skyddas på samma sätt som en databasserver. En slumpmässigt namngiven standardunderkatalog som använder version 3.1 gör det bara svårare att gissa sökvägen; den ersätter inte korrekt inställda filrättigheter eller åtkomstbegränsningar på webbservern.

I projektet rekommenderas att, DB_PATH att ange som en absolut sökväg utanför webbrotkatalogen. PHP behöver skrivrättigheter där, medan webbservern inte får leverera databasfilen direkt. Denna åtskillnad minskar risken för att en felaktig konfiguration i den offentligt tillgängliga katalogen gör filen åtkomlig. Vid driftsättning, behörighetshantering och säkerhetskopiering måste den valda lagringsplatsen uttryckligen beaktas.

När det gäller säkerhetskopior är det, sedan versionsserien 3.1, avgörande att inte ange något historiskt filnamn eller någon förutbestämd standardväg. Pluginet kan hämta den faktiska vägen via DB_PATH göra den tillgänglig under körning; verktyg för säkerhetskopiering, migrering och återställning måste därför identifiera den efter att WordPress har laddats. Innan du släpper den till produktion bör du utföra återställningen i en separat miljö och dokumentera den nödvändiga sökvägen, konfigurationen och arbetsstegen.

Sedan plugin-version 3.0 använder integrationen WAL-läget som standard. Förutom huvuddatabasen kan då kompletterande filer med filändelserna -wal och -shm uppstår. Kontrollera därför noga om det säkerhetsverktyg som används stöder WAL-driften i den aktiva SQLite-databasen och tar hänsyn till dessa komponenter. Utan ett sådant verktygsgodkännande går det inte att skapa en konsekvent säkerhetskopia genom att enbart kopiera huvudfilen.

Den minsta versionen av SQLite (3.37.0) som anges av tillägget utgör den tekniska nedre gränsen för integrationen. För driften bör du dessutom hålla koll på vilken SQLite-version PHP faktiskt använder och inkludera säkerhets- och felkorrigeringar för de använda PHP- och SQLite-paketen i den regelbundna uppdateringsprocessen. Utan en lämplig källkod i det befintliga källkodsarkivet går det dock inte att dra några tillförlitliga slutsatser om enskilda nyare SQLite-versioner eller specifika backports.

Export- och säkerhetskopieringsverktyg bör inte användas enbart för att de är välkända från MySQL- eller MariaDB-installationer. Kontrollera för det specifika verktyget om det stöder SQLite-databasen i den aktuella DB_PATH och stöds i det konfigurerade loggläget. Utför därefter en återställning i den avsedda värdmiljön och dokumentera om databasvägen, nödvändiga databaskomponenter och WordPress-konfigurationen sammanförs fullständigt.

Att identifiera konflikter och granska dem på ett målinriktat sätt

Övergången bör inledningsvis ske i en staging- eller testmiljö, inte i den första produktiva utrullningen. Registrera befintliga filer före installationen under wp-content/db.php samt plugins, MU-plugins och anpassade tillägg som använder MySQL direkt. En andra drop-in-databas kan inte köras parallellt; därför kontrollerar integrationsprocessen om sådana konflikter föreligger.

Kontrollera därefter konkreta arbetsflöden istället för bara startsidan: inloggning och administration, innehållsskapande, sökning, formulär, schemalagda uppgifter, import och export samt säkerhetskopiering och återställning. Upprepa testerna efter uppdateringar av plugins och WordPress. Integrationslagret hanterar MySQL-syntax för SQLite, men det stöd som beskrivs i projektet ersätter inte en kontroll av egna frågor eller mer sällsynta funktioner i ett tillägg.

Vanliga inredningsmisstag är brist på pdo_sqlite respektive pdo eller otillräckliga skrivrättigheter för databaskatalogen. Lika problematiskt är antagandet att aktiveringen överför innehåll från en befintlig MySQL- eller MariaDB-installation: den skapar en separat SQLite-databas, inte automatiskt en datamigrering. Inte heller flyttar en ny DB_PATH någon befintlig fil, utan pekar istället på en annan plats.

Om väntetider uppstår vid hög belastning bör du först undersöka vilka åtgärder som skriver samtidigt: till exempel beställningar, formulärhantering, REST-förfrågningar eller bakgrundsuppgifter. SQLite tillåter flera läsare, men serialiserar skrivoperationer per databasfil; flera webbservrar ökar dessutom kraven på databasarkitekturen. Detta kan inte jämföras med låsmekanismerna i MySQL-InnoDB. För orsaksanalys av konventionella WordPress-databaser kan artikeln om samtidiga databasåtkomster och lås.

Att välja rätt databasstrategi

SQLite är ett acceptabelt val för WordPress om webbplatsen körs på ett enskilt system, huvudsakligen används för läsning och antalet samtidiga ändringar är begränsat och känt. Detta passar bättre för lokal utveckling, demos eller små redaktionella webbplatser än för applikationer med många transaktioner. En förutsättning är dock att det faktiskt använda temat, pluginsen, importverktygen och alla egna databasåtkomster har bevisad kompatibilitet.

Vid distribuerade installationer, flera webbservrar eller skrivoperationer som sker samtidigt gäller följande: MySQL eller MariaDB den lämpligare databasstrategin. Detta gäller särskilt webbutiker med beställningar, boknings- och biljettsystem, community-funktioner och automatiserade gränssnitt med många skrivande förfrågningar. Det avgörande är inte ett generellt besökarantal, utan om oberoende processer samtidigt måste ändra samma databas. För direkt samtidig databasåtkomst från flera värdar via ett nätverk rekommenderar SQLite i princip ett klient-server-system.

För en befintlig webbplats innebär ett plattformsbyte dessutom inte automatiskt ett prestandaprojekt. Objekt- eller sidbaserad caching kan minska databasfrågor och PHP-bearbetning utan att ersätta MySQL eller MariaDB. Caching och SQLite löser därmed olika uppgifter: det förstnämnda minskar återkommande bearbetning, medan det sistnämnda förändrar databasens lagrings- och driftsmodell. De officiella WordPress-kraven anger fortfarande MariaDB eller MySQL som standardkrav för databaser.

Innan godkännandet bör en ”Go/No-Go”-granskning åtminstone omfatta följande punkter:

• Arkitektur: Kan WordPress köras kontinuerligt på en enda server utan att flera värdar behöver öppna samma SQLite-fil direkt via ett nätverksfilsystem?
• Skrivmönster: Begränsas parallella beställningar, bokningar, formulär, REST- eller AJAX-skrivoperationer och testas de i en separat miljö?
• Kompatibilitet: Fungerar teman, plugins, MU-plugins och egna SQL-frågor i testmiljön?
• Drop-ins: Finns det några konflikter mellan wp-content/db.php och databas- eller cachelösningar?
• Migrering: Finns det tydliga dokument som visar att aktiveringen inte överför något innehåll från MySQL eller MariaDB?
• Körningstid: Uppfyller det SQLite-bibliotek som laddas av PHP minimikravet på plugin-versionen, och ingår uppdateringar av PHP, SQLite och pluginet i underhållsprocessen?
• Säkerhet: Har säkerhetskopieringen fastställt den aktuella DB_PATH, stöder den den använda journalföringsmoden, och har en återställning utförts och dokumenterats i en separat miljö?
• Drift: Säkerställs uppdateringar av tillägget och WordPress genom en repeterbar testrutin?