SQLite som WordPress-database: Udviklingsstatus, begrænsninger og anvendelsestilfælde

At sætte WordPress og SQLite i den rette sammenhæng

WordPress understøtter i øjeblikket ikke SQLite som en databaseplatform, der kan vælges som standard i kernen. De officielle systemkrav angiver fortsat MySQL eller MariaDB; SQLite er ikke en del af standardkravene til en WordPress-installation. Hvis man kører WordPress med SQLite, ændrer man derfor ikke blot en indstilling i kernen, men udvider WordPress med et eget integrationslag.

Dette lag udgør plugin'et Integration af SQLite-database klar. Det er tilgængeligt i WordPress.org-plugin-kataloget og udvikles som et community- eller feature-plugin. Formålet er at afprøve en SQLite-implementering og indsamle feedback med henblik på en eventuel senere integration i kernen. Tilstedeværelsen i WordPress.org-økosystemet betyder altså ikke, at det er godkendt som en fast del af en normal WordPress-installation.

Initiativet har været undervejs i længere tid: I september 2022 blev der i WordPress-Core-teamet offentligt fremsat et forslag om på lang sigt at yde officiel støtte til SQLite. Siden januar 2023 har implementeringen kunnet hentes som et selvstændigt plugin; den daværende henvisning til Performance Lab beskriver et udviklingstrin, ikke den nuværende standardmetode for alle WordPress-websteder.

For at kunne foretage en pålidelig klassificering er versionsnummeret afgørende. På undersøgelsestidspunktet den 18. oktober 2026 er v3.1.0 fra den 8. oktober 2026 den stabile udgivelsesversion. Oplysninger fra udviklingsgrenen må ikke uden videre betragtes som egenskaber ved denne stabile version. Omvendt ville det være forkert at sidestille det aktive plugin med en generel produktiv frigivelse til alle WordPress-anvendelsessituationer alene af den grund.

Læserens spørgsmål kan derfor kun delvist besvares med ja: SQLite kan være en fornuftig løsning til klart afgrænsede installationer, f.eks. til udvikling, demoer eller små websteder på enkeltstående servere med overskuelige ændringer. Til distribuerede, skriveintensive eller forretningskritiske installationer er MySQL eller MariaDB fortsat det regulært understøttede og oftest mere passende grundlag. Arkitekturen, skrivemønstrene og den faktiske kompatibilitet af den anvendte stack er afgørende.

Fildatabase, drop-in og SQL-kompatibilitet

Den grundlæggende forskel ligger i lagringsmodellen. SQLite er en Fildatabase: Dataene lagres lokalt i en databasefil på filsystemet. MySQL og MariaDB fungerer derimod som selvstændige databasetjenester, som WordPress kommunikerer med via en serverforbindelse. SQLite kan derfor muliggøre et mere strømlinet miljø, men forudsætter en passende lokal lagringsplads og de rette filrettigheder.

WordPress-kernen, temaer og de fleste udvidelser bruger den velkendte grænseflade til databaseadgang wpdb. Pluginet erstatter det sædvanlige databaselag via drop-in-funktionen wp-content/db.php. Dette drop-in opfanger forespørgslerne og fungerer som mellemled mellem den forventede MySQL-baserede WordPress-verden og SQLite. Dermed forbliver brugergrænsefladen den samme for mange komponenter, selvom databasegrundlaget ændres.

Mellemlaget er det afgørende punkt bag den forenklede påstand om, at „WordPress kører på SQLite“. WordPress genererer ikke automatisk SQLite-specifik SQL. Projektdokumentationen i udviklingsgrenen trunk beskriver en MySQL-parser, der efterligner SQL-grammatikken og de nødvendige funktioner til SQLite. Dette forklarer udviklingsmetoden, men er hverken et løfte om en stabil version eller en garanti for, at hver enkelt MySQL-forespørgsel eller -udvidelse er kompatibel uden tilpasning.

Du bør være særlig omhyggelig med at kontrollere udvidelser, der genererer SQL direkte, kræver databasefunktioner eller administrerer egne tabeller på en usædvanlig måde. Dette gælder også importværktøjer, rapporteringsværktøjer og vedligeholdelsesskripter. Et tema eller plugin kan fungere under normale omstændigheder, men alligevel mislykkes ved en sjælden administratorhandling, en opdatering eller en specifik forespørgsel på grund af en MySQL-egenskab, der ikke er taget højde for.

Forskellene i skema, metadata og typiske forespørgsler er stadig relevante for vurderingen. Det interne overblik over WordPress-databasetabeller og deres ydeevne hjælper med at identificere databasekrævende udvidelser og egne tabeller som mulige kontrolpunkter. SQLite-integration erstatter hverken en analyse af sådanne forespørgsler eller ansvaret for at teste tilpasninger uden for WordPress’ standardgrænseflade, inden de tages i brug.

Hvornår er SQLite teknisk set en rimelig løsning?

En fornuftig beslutning kan ikke træffes ud fra et samlet besøgstal. Det afgørende er Skrivekonkurrence: SQLite tillader flere samtidige læsere, men der kan kun finde én skriveoperation sted ad gangen pr. databasefil. Hvis ændringer finder sted samtidigt, må yderligere skriveoperationer vente. SQLite-dokumentationen anbefaler en klient-server-database, hvis der er mange uafhængige klienter, flere computere eller mange samtidige skriveoperationer.

Anvendelsesområder, der let kan afgrænses, er lokal udvikling, kurser, demonstrationer og kortvarige testmiljøer. Her er det ikke nødvendigt at opsætte en separat MySQL- eller MariaDB-tjeneste, samtidig med at plugin- og temastakken kan testes på en kontrolleret måde. Selv en lille hjemmeside på en enkelt server kan være velegnet, hvis den hovedsageligt læses, og redaktionelle ændringer foretages sjældent og ikke samlet på én gang.

En enkel virksomhedshjemmeside, en personlig blog eller en kampagneside er dog ikke nødvendigvis egnede. Kontaktformularer, medlemsområder, nyhedsbrevsintegrationer eller individuelt programmerede slutpunkter kan udløse yderligere skriveoperationer. Kontroller derfor ikke kun sidevisninger, men også opdateringer af indstillinger, formularindtastninger, planlagte opgaver samt dataændringer via plugins og eksterne grænseflader.

For webshops med ordrer, reservations- og billetsystemer, aktive fællesskaber eller applikationer med mange AJAX- og REST-skriveoperationer er denne begrænsning som regel mere væsentlig. Her kan flere brugere næsten samtidigt gemme ordrer, ændre tilgængelighed eller oprette indlæg. Flere webservere bag en load balancer passer heller ikke til den lokale filtilgang, som SQLite forudsætter i dette anvendelsestilfælde.

Caching løser en anden opgave end SQLite. Side- eller objektcaching kan reducere gentagne læseadgange og dermed databaseforespørgsler; det gør dog ikke en skriveintensiv applikation til en SQLite-installation med få konflikter. Omvendt erstatter SQLite ikke et cache-koncept. For eksisterende hjemmesider kan det derfor være den mindst risikofyldte løsning at beholde MySQL eller MariaDB sammen med passende caching, uden at skifte databaseplatform.

Systematisk evaluering af scenarier med SQLite

Det er ikke antallet af besøgende, der afgør, om SQLite passer til WordPress, men samspillet mellem skriveoperationer, serverkonfiguration og udvidelser. SQLite kan håndtere parallelle læseadgange, men kan ikke udføre skriveoperationer på den samme databasefil parallelt i ubegrænset omfang. Derfor er et enkelt websted med mange sidevisninger ikke automatisk uegnet, mens samtidig udløste ordrer eller bookinger kan være kritiske.

Tabellen er en foreløbig udvælgelse, ikke en endelig godkendelse. Især på en lille virksomheds hjemmeside kan en CRM-formular, et medlemsområde eller en ekstern automatiseringstjeneste gøre en side, hvor der sjældent skrives indlæg, til en side med stor skrivebelastning. Omvendt er en blog med mange læsere stadig en plausibel kandidat, hvis kommentarer, formularer og administrative ændringer er overskuelige. Pluginet påpeger selv, at egnetheden afhænger af trafik og skrivebelastning.

Multisite er beskrevet i projektdokumentationen for udviklingsgrenen som et scenarie, der kan konfigureres; desuden indeholder repositoryet egne tests hertil. Dette betyder dog ikke, at der er givet en generel produktionsgodkendelse til store netværk med mange redaktører, websteder eller integrationer. Behandl derfor et netværk som et selvstændigt kompatibilitetstilfælde, og kontroller de faktisk anvendte administrations-, opdaterings- og indholdsprocesser.

Det obligatoriske trin i praksis er en test af den konkrete stack i et isoleret miljø. Dette omfatter det aktive tema, alle produktive plugins, individuelle MU-plugins, importværktøjer, formularer, REST-endepunkter samt sikkerheds- og overvågningsværktøjer. Det afgørende er ikke kun, om siderne indlæses: Hver udvidelse med egne SQL-antagelser eller hyppige ændringer skal pålideligt gennemløbe SQLite-laget.

Opsætning og sikker konfiguration af stier

Værktøjet er velegnet til en ny testinstallation eller en bevidst planlagt SQLite-installation, men ikke som en hurtig løsning til en eksisterende produktionsmiljø. Før aktivering skal PHP have udvidelsen pdo_sqlite samt PDO-understøttelse; desuden kræver plugin'et SQLite fra version 3.37.0. PHP skal have skrivrettigheder til den valgte databasemappe. Konfigurationsdialogen kontrollerer disse betingelser og registrerer desuden eksisterende, konfliktende database-drop-ins.

Den angivne minimumsversion af SQLite er et teknisk krav til plugin’et, men ikke en generel garanti for alle produktive anvendelsessituationer. Siden plugin-version 3.0 er Write-Ahead Logging aktiveret som standard. Administratorer bør derfor kontrollere, hvilket SQLite-bibliotek den anvendte PHP-runtime rent faktisk indlæser, og medtage opdateringer af plugins, PHP og SQLite i deres vedligeholdelses- og kompatibilitetstjek.

Vær særlig opmærksom på wp-content/db.php. Denne fil er det centrale WordPress-drop-in til databaselaget; to løsninger kan ikke bruge den samtidigt. Hvis der allerede findes et drop-in der, f.eks. til en anden databaseforbindelse eller en caching-løsning, skal det afklares inden installationen, hvilken komponent det stiller til rådighed, og om det er muligt at fjerne det på en korrekt måde.

Den stabile version 3.1.0 bruger som standard tilfældigt navngivne undermapper under wp-content/database/. Den fundne placering vises i db-path.php nedskrevet og via DB_PATH stillet til rådighed. Backup- og migrationsværktøjer må derfor ikke forudsætte historiske filnavne eller en tilfældig standardsti. De tidligere konstanter DB_DIR og DB_FILE er markeret som forældede i 3.1; DB_PATH har forrang.

Ved en planlagt nyinstallation anbefaler projektet en absolut sti uden for det offentligt tilgængelige webkatalog. Målmappen skal være skrivbar for PHP-processen. Følgende indstilling skal placeres i wp-config.php og er et eksempel på en konfiguration, ikke en vejledning til efterfølgende ændring af et eksisterende websted.

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

Advarsel: En nyindstillet DB_PATH flytter ikke en eksisterende databasefil. Den vælger en anden placering. Hvis værdien ændres uden forudgående forberedelse, kan WordPress derfor komme til at bruge en anden eller tom database. Planlæg stien, adgangsrettighederne, sikkerhedskopieringen og en gendannelsestest i fællesskab, inden den tages i brug i produktionsmiljøet.

Den tilfældige mappestruktur i version 3.1 mindsker blot forudsigeligheden af standardstien. Den erstatter hverken filsystemrettigheder eller en lagringsplads, der er pålideligt beskyttet mod offentlig eksponering. Den sikreste løsning er den anbefalede sti uden for webroden; hvis der vælges en anden placering, skal webserverens adgang til denne ligeledes udelukkes på en pålidelig måde.

Ingen skift af database ved aktivering

På et eksisterende WordPress-websted med MySQL eller MariaDB udgør aktivering af SQLite Database Integration ikke en migrering. Pluginet opretter en separat, i første omgang tom SQLite-database. Indlæg, brugere, indstillinger, mediefiler og plugin-data fra den hidtidige database overføres ikke automatisk. Hvis integrationen senere deaktiveres, opretter WordPress igen forbindelse til den hidtidige database; ændringer, der er foretaget i SQLite, overføres ikke tilbage.

Denne adskillelse er nyttig i forbindelse med test, men afgørende ved produktionsskift. Hvis man rent faktisk ønsker at overføre indhold til en anden databaseplatform, har man brug for en egen, gennemsigtig migrationsplan, der omfatter dataoverførsel, kontrol af tegnsæt og indstillinger samt en nødplan. Det er ikke nok blot at skifte drop-in for at erstatte denne proces.

Betegnelsen separate datasæt Dette skal forstås bogstaveligt: Under drift af SQLite kan de to databaser indeholde forskelligt indhold. Et testindlæg i SQLite vises ikke pludselig i MySQL eller MariaDB, når SQLite er deaktiveret. Tilsvarende forbliver et nyt MySQL-indlæg usynligt, så længe WordPress bruger SQLite-filen som aktiv datakilde.

Repositoriet wp-sqlite-db betegner sig selv som et selvstændigt projekt med en enkelt SQLite-drop-in og henviser til den oprindelige SQLite-integration. Det skal derfor ikke sidestilles med det aktuelle WordPress-repository. Filer, konfigurationsværdier og vejledninger fra dette projekt bør ikke overføres til den aktuelle SQLite-databaseintegration; det er altid dokumentationen for det konkret anvendte projekt, der er gældende.

For eksisterende hjemmesider er det ofte den mindst risikable løsning at beholde MySQL eller MariaDB og undersøge flaskehalse separat. Side- eller objektcaching kan reducere antallet af databaseforespørgsler, men erstatter ikke datamigrering og løser ikke kompatibilitetsproblemer i forbindelse med SQLite-integrationen. Denne oversigt hjælper med at klassificere typiske WordPress-forespørgsler og caching-tilgange til WordPress-ydeevne og optimering af caching.

Beskyttelse og konsekvent sikkerhedskopiering af SQLite-databaser

I SQLite ligger WordPress-databasen i en fil på serveren. Den kan blandt andet indeholde indhold, brugerkonti, indstillinger og konfigurationsdata og skal derfor beskyttes på samme måde som en databaseserver. Et tilfældigt navngivet standardunderkatalog, der bruger version 3.1, gør det blot sværere at gætte en sti; det erstatter ikke korrekt indstillede filrettigheder eller adgangsbegrænsninger på webserveren.

Projektet anbefaler, at, DB_PATH at angive som en absolut sti uden for webroden. PHP skal have skriverettigheder der, mens webserveren ikke må levere databasefilen direkte. Denne adskillelse mindsker risikoen for, at en forkert konfiguration i det offentligt tilgængelige bibliotek gør filen tilgængelig. Implementering, rettighedsstyring og sikkerhedskopiering skal udtrykkeligt tage højde for den valgte placering.

Når det gælder sikkerhedskopier, er det afgørende, at man fra og med versionsserien 3.1 ikke indtaster et historisk filnavn eller en vilkårlig standardsti. Pluginet kan hente den faktiske sti via DB_PATH gøre den tilgængelig under kørsel; backup-, migrations- og gendannelsesværktøjer skal derfor finde den efter indlæsning af WordPress. Inden du tager den i brug, bør du gennemføre gendannelsen i et separat miljø og dokumentere den nødvendige sti, konfigurationen og de enkelte trin.

Siden plugin-version 3.0 bruger integrationen som standard WAL-tilstand. Her kan der ud over hoveddatabasen oprettes ledsagerfiler med filendelserne -wal og -shm opstår. Kontroller derfor nøje, om det anvendte sikkerhedskopieringsværktøj understøtter WAL-drift af den kørende SQLite-database og tager højde for disse komponenter. Uden en sådan godkendelse af værktøjet kan der ikke udledes en konsistent sikkerhedskopi ved blot at kopiere hovedfilen.

Den minimumsversion af SQLite (3.37.0), som pluginet angiver, udgør den tekniske nedre grænse for integrationen. I forbindelse med driften bør du desuden holde øje med, hvilken SQLite-version PHP rent faktisk bruger, og indarbejde sikkerheds- og fejlrettelser til de anvendte PHP- og SQLite-pakker i den løbende opdateringsproces. Uden en passende kilde i den eksisterende kildebase kan der dog ikke udledes nogen pålidelig anbefaling for enkelte nyere SQLite-versioner eller bestemte backports.

Eksport- og sikkerhedskopieringsværktøjer bør ikke anvendes alene af den grund, at de er kendt fra MySQL- eller MariaDB-installationer. Kontroller for det pågældende værktøj, om det understøtter SQLite-databasen i den aktuelle DB_PATH og understøttes i den konfigurerede logtilstand. Udfør derefter en gendannelse i det påtænkte hostingmiljø, og dokumenter, om databasestien, de nødvendige databasekomponenter og WordPress-konfigurationen bliver fuldt ud sammenført.

At identificere konflikter og undersøge dem målrettet

Overgangen skal først foregå i en staging- eller testinstans, ikke i den første produktive udrulning. Registrer eksisterende filer før installationen under wp-content/db.php samt plugins, MU-plugins og brugerdefinerede udvidelser, der forudsætter direkte adgang til MySQL. En anden database-drop-in kan ikke køre sideløbende; installationsprocessen for integrationen kontrollerer derfor for sådanne konflikter.

Tjek derefter de konkrete arbejdsgange i stedet for kun startsiden: login og administration, oprettelse af indhold, søgning, formularer, planlagte opgaver, import og eksport samt sikkerhedskopiering og gendannelse. Gentag testene efter opdateringer af plugins og WordPress. Integrationslaget behandler MySQL-syntaks til SQLite, men den støtte, der er beskrevet i projektet, erstatter ikke en kontrol af egne forespørgsler eller sjældne funktioner i et plugin.

Almindelige fejl ved indretning er manglende pdo_sqlite henholdsvis pdo eller utilstrækkelige skriverettigheder til databasemappen. Lige så problematisk er antagelsen om, at aktiveringen overtager indholdet fra en eksisterende MySQL- eller MariaDB-installation: Den opretter en separat SQLite-database, men foretager ikke automatisk en datamigrering. Selv en ny DB_PATH flytter ikke en eksisterende fil, men henviser blot til en anden placering.

Hvis der opstår ventetider under belastning, skal du først undersøge, hvilke handlinger der skriver samtidigt: f.eks. ordrer, formularbehandling, REST-forespørgsler eller baggrundsopgaver. SQLite tillader flere læsere, men serieliserer skriveoperationer pr. databasefil; flere webservere øger desuden kravene til databasearkitekturen. Dette kan ikke sidestilles med låsemekanismerne i MySQL-InnoDB. Til årsagsanalysen ved traditionelle WordPress-databaser er artiklen om samtidige databaseadgange og låse.

Valg af den rette databasestrategi

SQLite er et acceptabelt valg til WordPress, hvis hjemmesiden kører på et enkelt system, hovedsageligt bruges til læsning, og antallet af samtidige ændringer er begrænset og kendt. Dette passer bedre til lokal udvikling, demoer eller små redaktionelle hjemmesider end til applikationer med mange transaktioner. En forudsætning er dog, at det faktisk anvendte tema, plugins, importværktøjer og alle egne databaseadgange er dokumenteret kompatible.

Ved distribuerede installationer, flere webservere eller skriveoperationer, der finder sted på samme tid, forbliver MySQL eller MariaDB den mest passende databasestrategi. Dette gælder især webshops med ordrer, reservations- og billetsystemer, community-funktioner og automatiserede grænseflader med mange skriveforespørgsler. Det afgørende er ikke et samlet besøgstal, men om uafhængige processer skal ændre den samme database samtidigt. Til direkte, samtidig databaseadgang fra flere værter via et netværk anbefaler SQLite generelt et klient-server-system.

For en eksisterende hjemmeside er et platformsskifte desuden ikke automatisk et ydeevneprojekt. Objekt- eller sidebaseret caching kan reducere databaseforespørgsler og PHP-arbejde uden at erstatte MySQL eller MariaDB. Caching og SQLite løser dermed forskellige opgaver: Førstnævnte reducerer gentagen databehandling, mens sidstnævnte ændrer databasens lagrings- og driftsmodel. De officielle WordPress-krav angiver fortsat MariaDB eller MySQL som standardkrav til databasen.

Inden godkendelsen bør en »Go/No-Go«-vurdering som minimum omfatte følgende punkter:

• Arkitektur: Kører WordPress permanent på en enkelt server, uden at flere værter skal åbne den samme SQLite-fil direkte via et netværksfilsystem?
• Skrivemønstre: Er parallelle ordrer, bogføringer, formularer samt REST- eller AJAX-skriveoperationer begrænset og testet i et separat miljø?
• Kompatibilitet: Fungerer temaet, plugins, MU-plugins og egne SQL-forespørgsler i testinstansen?
• Drop-ins: Er wp-content/db.php fri for konflikter med database- eller caching-løsninger?
• Migrering: Er det klart dokumenteret, at aktiveringen ikke overfører noget indhold fra MySQL eller MariaDB?
• Kørselstid: Opfylder det SQLite-bibliotek, der indlæses af PHP, pluginets minimumskrav til version, og er opdateringer af PHP, SQLite og pluginet integreret i vedligeholdelsesprocessen?
• Sikkerhed: Fastslår sikkerhedskopien den aktuelle DB_PATH, understøtter den den anvendte journaltilstand, og er der udført og dokumenteret en gendannelse i et adskilt miljø?
• Drift: Er opdateringer af plugin’et og WordPress sikret ved hjælp af en gentagelig testprocedure?