SQLite jako baza danych WordPressa: stan rozwoju, ograniczenia i zastosowania

Jak właściwie zrozumieć WordPress i SQLite

WordPress nie obsługuje obecnie SQLite jako standardowej platformy bazodanowej dostępnej w rdzeniu. Oficjalne wymagania systemowe nadal wskazują na MySQL lub MariaDB; SQLite nie należy do standardowych wymagań instalacji WordPressa. Kto korzysta z WordPressa z SQLite, nie zmienia zatem po prostu ustawienia rdzenia, lecz uzupełnia WordPress o własną warstwę integracyjną.

Tę warstwę zapewnia wtyczka Integracja z bazą danych SQLite Gotowe. Jest dostępne w katalogu wtyczek WordPress.org i jest rozwijane jako wtyczka społecznościowa lub funkcjonalna. Jego celem jest przetestowanie implementacji SQLite oraz zebranie opinii na potrzeby ewentualnej późniejszej integracji z rdzeniem. Obecność w ekosystemie WordPress.org nie oznacza zatem, że wtyczka ta została zatwierdzona jako stały element standardowej instalacji WordPressa.

Inicjatywa ta ma długą historię: we wrześniu 2022 roku w zespole WordPress Core publicznie zaproponowano, aby w perspektywie długoterminowej oficjalnie wspierać SQLite. Od stycznia 2023 r. implementację tę można pobrać jako samodzielną wtyczkę; ówczesne odniesienie do Performance Lab opisuje etap rozwoju, a nie obecny standardowy sposób postępowania dla każdej witryny WordPress.

Aby zapewnić rzetelną klasyfikację, należy brać pod uwagę numer wersji. W momencie przeprowadzania badania, tj. 18 października 2026 r., stabilną wersją wydaną jest wersja v3.1.0 z 8 października 2026 r. Funkcjonalności pochodzące z gałęzi rozwojowej nie mogą być automatycznie uznawane za cechy tej stabilnej wersji. Z drugiej strony błędem byłoby utożsamianie aktywnej wtyczki wyłącznie na tej podstawie z ogólnym dopuszczeniem do użytku produkcyjnego w każdym przypadku zastosowania WordPressa.

Na pytanie czytelnika można zatem odpowiedzieć „tak” tylko z pewnymi zastrzeżeniami: SQLite może być sensownym rozwiązaniem w przypadku jasno określonych instalacji, na przykład do celów programistycznych, prezentacji lub małych stron internetowych opartych na pojedynczym serwerze, gdzie zmiany są łatwe do ogarnięcia. W przypadku instalacji rozproszonych, wymagających intensywnego zapisu danych lub o znaczeniu krytycznym dla działalności firmy, MySQL lub MariaDB pozostają standardowo obsługiwanymi i zazwyczaj bardziej odpowiednimi rozwiązaniami. Decydujące znaczenie mają architektura, wzorce zapisu oraz rzeczywista kompatybilność stosowanego stosu technologicznego.

Baza danych plików, kompatybilność typu „drop-in” i kompatybilność z SQL

Podstawowa różnica polega na modelu pamięci. SQLite to Baza danych plików: Dane są przechowywane lokalnie w pliku bazy danych w systemie plików. Natomiast MySQL i MariaDB działają jako samodzielne usługi bazodanowe, z którymi WordPress komunikuje się za pośrednictwem połączenia z serwerem. SQLite może zatem zapewnić bardziej uproszczone środowisko, ale wymaga odpowiedniej lokalizacji przechowywania danych oraz odpowiednich uprawnień do plików.

Rdzeń WordPressa, motywy oraz większość wtyczek wykorzystują do dostępu do bazy danych znany interfejs wpdb. Wtyczka zastępuje standardową warstwę bazy danych za pomocą rozwiązania typu „drop-in” wp-content/db.php. Ten moduł typu „drop-in” przechwytuje zapytania i pełni rolę pośrednika między oczekiwanym środowiskiem WordPressa opartym na MySQL a bazą danych SQLite. Dzięki temu interfejs aplikacji pozostaje taki sam dla wielu komponentów, mimo że zmienia się infrastruktura bazy danych.

Warstwa pośrednicząca jest kluczowym elementem stojącym za skróconym stwierdzeniem „WordPress działa na SQLite“. WordPress nie generuje automatycznie kodu SQL specyficznego dla SQLite. Dokumentacja projektu w gałęzi rozwojowej trunk opisuje parser MySQL, który odtwarza gramatykę SQL oraz funkcje wymagane przez SQLite. Wyjaśnia to podejście do rozwoju, ale nie stanowi ani obietnicy wydania stabilnej wersji, ani gwarancji, że każde indywidualne zapytanie lub rozszerzenie MySQL będzie kompatybilne bez konieczności dostosowania.

Szczególną uwagę należy zwrócić na rozszerzenia, które bezpośrednio generują kod SQL, wymagają funkcji bazy danych lub w nietypowy sposób zarządzają własnymi tabelami. Dotyczy to również narzędzi do importowania danych, narzędzi do raportowania oraz skryptów konserwacyjnych. Motyw lub wtyczka może działać poprawnie w standardowym trybie pracy, a mimo to zawieść podczas rzadko wykonywanej czynności administracyjnej, aktualizacji lub specjalnego zapytania z powodu nieodzwierciedlonej specyfiki MySQL.

Różnice w schemacie, metadanych i typowych zapytaniach nadal mają znaczenie dla oceny. Wewnętrzny przegląd dotyczący Tabele bazy danych WordPressa i ich wydajność pomaga w klasyfikowaniu rozszerzeń intensywnie korzystających z baz danych oraz własnych tabel jako potencjalnych punktów kontrolnych. Integracja z SQLite nie zastępuje ani analizy takich zapytań, ani obowiązku przetestowania przed wdrożeniem wszelkich modyfikacji wykraczających poza standardowy interfejs WordPressa.

Kiedy stosowanie SQLite jest uzasadnione z technicznego punktu widzenia

Rozsądna decyzja nie wynika z ogólnej liczby odwiedzających. Decydujące znaczenie ma Konkurs na najlepszy tekst: SQLite pozwala na równoczesny dostęp wielu czytelników, ale w danym pliku bazy danych może odbywać się tylko jedna operacja zapisu. Jeśli zmiany zbiegają się w czasie, kolejne operacje zapisu muszą poczekać. Dokumentacja SQLite zaleca stosowanie modelu bazy danych typu klient-serwer w przypadku dużej liczby niezależnych klientów, wielu komputerów lub wielu równoczesnych operacji zapisu.

Wyraźnie wyodrębnione obszary zastosowań to rozwój lokalny, szkolenia, prezentacje oraz krótkotrwałe instancje testowe. Nie ma tam potrzeby konfigurowania oddzielnej usługi MySQL lub MariaDB, a jednocześnie można w kontrolowany sposób testować zestaw wtyczek i motywów. Również niewielka strona internetowa na pojedynczym serwerze może się sprawdzić, o ile jest ona głównie przeglądana, a zmiany redakcyjne są rzadkie i nie występują w sposób skumulowany w czasie.

Jednak prosta strona firmowa, osobisty blog czy strona kampanii niekoniecznie się do tego nadają. Formularze kontaktowe, strefy członkowskie, integracje z newsletterami lub indywidualnie zaprogramowane punkty końcowe mogą powodować dodatkowe operacje zapisu. Dlatego należy sprawdzać nie tylko wywołania stron, ale także aktualizacje opcji, dane wprowadzone w formularzach, zaplanowane zadania oraz zmiany danych spowodowane przez wtyczki i interfejsy zewnętrzne.

W przypadku sklepów internetowych obsługujących zamówienia, systemów rezerwacji i sprzedaży biletów, aktywnych społeczności lub aplikacji z dużą liczbą operacji zapisu AJAX i REST ograniczenie to ma zazwyczaj większe znaczenie. W takich sytuacjach wielu użytkowników może niemal jednocześnie zapisywać zamówienia, zmieniać dostępność produktów lub tworzyć wpisy. Kilka serwerów WWW podłączonych do urządzenia równoważącego obciążenie również nie pasuje do lokalnego podejścia do plików, którego wymaga SQLite w tym przypadku.

Buforowanie służy innym celom niż SQLite. Buforowanie stron lub obiektów może ograniczyć powtarzające się operacje odczytu, a tym samym zapytania do bazy danych; nie sprawia jednak, że aplikacja intensywnie zapisująca dane stanie się instalacją SQLite o niskim poziomie konfliktów. Z drugiej strony SQLite nie zastępuje koncepcji buforowania. W przypadku istniejących stron internetowych utrzymanie MySQL lub MariaDB w połączeniu z odpowiednim buforowaniem może zatem stanowić rozwiązanie wiążące się z mniejszym ryzykiem, pozwalające uniknąć zmiany platformy bazodanowej.

Systematyczna ocena scenariuszy z wykorzystaniem SQLite

O tym, czy SQLite nadaje się do WordPressa, nie decyduje liczba odwiedzających, lecz współdziałanie operacji zapisu, konfiguracji serwera i rozszerzeń. SQLite może obsługiwać równoległe operacje odczytu, ale nie może wykonywać operacji zapisu w tym samym pliku bazy danych w dowolnej liczbie równoległych procesów. Dlatego pojedyncza strona internetowa z dużą liczbą odsłon nie jest automatycznie nieodpowiednia, podczas gdy jednocześnie generowane zamówienia lub rezerwacje mogą stanowić problem.

Tabela stanowi wstępną selekcję, a nie ostateczną decyzję. Zwłaszcza w przypadku małej strony firmowej formularz CRM, strefa członkowska lub zewnętrzna usługa automatyzacji mogą sprawić, że strona, na której rzadko pojawiają się nowe treści, stanie się obciążeniem pod względem pisania. Z drugiej strony blog z dużą liczbą czytelników pozostaje realnym kandydatem, o ile komentarze, formularze i zmiany administracyjne są w rozsądnym zakresie. Sama wtyczka wskazuje, że jej przydatność zależy od ruchu na stronie i obciążenia związanego z zapisywaniem danych.

W dokumentacji projektowej gałęzi rozwojowej funkcja Multisite została opisana jako scenariusz, który można skonfigurować; ponadto repozytorium zawiera oddzielne testy dotyczące tej funkcji. Nie oznacza to jednak ogólnego zatwierdzenia do wdrożenia w środowisku produkcyjnym w przypadku dużych sieci z wieloma redaktorami, witrynami lub integracjami. Należy zatem traktować sieć jako odrębny przypadek kompatybilności i sprawdzić faktycznie stosowane procesy zarządzania, aktualizacji oraz obsługi treści.

Obowiązkowym etapem praktycznym jest przetestowanie konkretnego stosu w oddzielnym środowisku. Obejmuje to aktywny motyw, wszystkie wtyczki produkcyjne, indywidualne wtyczki MU, narzędzia do importowania, formularze, punkty końcowe REST, a także narzędzia do tworzenia kopii zapasowych i monitorowania. Decydujące znaczenie ma nie tylko to, czy strony się ładują: każde rozszerzenie z własnymi założeniami dotyczącymi SQL lub częstymi zmianami musi niezawodnie przechodzić przez warstwę SQLite.

Instalacja i bezpieczna konfiguracja ścieżek

Rozwiązanie to nadaje się do nowej instalacji testowej lub starannie zaplanowanej instalacji SQLite, ale nie jako szybkie rozwiązanie dla istniejącego środowiska produkcyjnego. Przed aktywacją PHP musi mieć zainstalowane rozszerzenie pdo_sqlite wraz z obsługą PDO; ponadto wtyczka wymaga biblioteki SQLite w wersji 3.37.0 lub nowszej. PHP potrzebuje uprawnień do zapisu w wybranym katalogu bazy danych. Okno dialogowe konfiguracji sprawdza te warunki, a także wykrywa istniejące, powodujące konflikty moduły baz danych typu „drop-in”.

Podana minimalna wersja SQLite stanowi techniczne wymaganie wtyczki, ale nie jest to ogólna gwarancja dla każdego przypadku zastosowania w środowisku produkcyjnym. Od wersji 3.0 wtyczki Rejestrowanie z wyprzedzeniem domyślnie włączone. Administratorzy powinni zatem sprawdzić, którą bibliotekę SQLite faktycznie ładuje używane środowisko uruchomieniowe PHP, oraz uwzględnić aktualizacje wtyczek, PHP i SQLite w swoich procedurach konserwacyjnych i testach zgodności.

Zwróć szczególną uwagę na wp-content/db.php. Ten plik stanowi główny moduł WordPressa obsługujący warstwę bazy danych; nie można korzystać z niego jednocześnie w dwóch rozwiązaniach. Jeśli w tym miejscu istnieje już moduł typu „drop-in”, na przykład dla innego połączenia z bazą danych lub rozwiązania buforującego, przed instalacją należy sprawdzić, jakie komponenty udostępnia i czy możliwe jest jego prawidłowe usunięcie.

Wersja stabilna 3.1.0 domyślnie wykorzystuje podkatalogi o losowych nazwach w katalogu wp-content/database/. Określona lokalizacja zostanie zapisana w db-path.php zapisano i przekazano poprzez DB_PATH udostępniono. Narzędzia do tworzenia kopii zapasowych i migracji nie mogą zatem zakładać istnienia historycznych nazw plików ani domyślnej ścieżki. Dawne stałe DB_DIR oraz DB_FILE są oznaczone w sekcji 3.1 jako przestarzałe; DB_PATH ma pierwszeństwo.

W przypadku planowanej nowej instalacji projekt zaleca użycie ścieżki bezwzględnej poza katalogiem internetowym dostępnym publicznie. Katalog docelowy musi mieć uprawnienia do zapisu dla procesu PHP. Poniższe ustawienie należy umieścić w pliku wp-config.php i stanowi przykład konfiguracji, a nie instrukcję dotyczącą późniejszej modyfikacji działającej strony internetowej.

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

Ostrzeżenie: Nowo ustawiony DB_PATH nie przenosi istniejącego pliku bazy danych. Wybiera inną lokalizację. Jeśli wartość ta zostanie zmieniona bez odpowiedniego przygotowania, WordPress może w związku z tym korzystać z innej lub pustej bazy danych. Przed wdrożeniem w środowisku produkcyjnym należy wspólnie zaplanować ścieżkę dostępu, uprawnienia, tworzenie kopii zapasowej oraz test przywracania danych.

Losowa struktura katalogów w wersji 3.1 ogranicza jedynie przewidywalność domyślnej ścieżki. Nie zastępuje ona ani uprawnień systemu plików, ani lokalizacji przechowywania, która byłaby niezawodnie zabezpieczona przed publicznym ujawnieniem. Najbezpieczniejsza jest zalecana ścieżka poza katalogiem głównym serwisu; w przypadku wyboru innej lokalizacji dostęp serwera WWW do niej musi być równie niezawodnie zablokowany.

Brak zmiany bazy danych poprzez aktywację

W przypadku istniejącej witryny WordPress z bazą danych MySQL lub MariaDB włączenie integracji z bazą danych SQLite nie wiąże się z migracją. Wtyczka tworzy oddzielną, początkowo pustą bazę danych SQLite. Wpisy, użytkownicy, opcje, odnośniki do multimediów oraz dane wtyczek z dotychczasowej bazy danych nie są automatycznie przenoszone. Jeśli integracja zostanie później wyłączona, WordPress ponownie połączy się z dotychczasową bazą danych; zmiany wprowadzone w SQLite nie zostaną przeniesione z powrotem.

To rozdzielenie jest przydatne podczas testów, ale ma zasadnicze znaczenie przy wdrażaniu zmian w środowisku produkcyjnym. Każdy, kto faktycznie chce przenieść dane na inną platformę bazodanową, potrzebuje własnego, przejrzystego planu migracji, obejmującego przeniesienie danych, sprawdzenie zestawów znaków i opcji, a także plan awaryjny. Samo przełączenie modułu drop-in nie może zastąpić tego procesu.

Nazwa oddzielne zbiory danych Należy to rozumieć dosłownie: podczas działania SQLite obie bazy danych mogą zawierać różne treści. Wpis testowy w SQLite nie pojawi się nagle w MySQL lub MariaDB po wyłączeniu tej bazy. Podobnie nowy wpis w MySQL pozostaje niewidoczny, dopóki WordPress korzysta z pliku SQLite jako aktywnego źródła danych.

Repozytorium wp-sqlite-db Projekt ten określa się jako samodzielny projekt z pojedynczym modułem „drop-in” dla SQLite i odwołuje się do pierwotnej integracji z SQLite. Nie należy go zatem utożsamiać z aktualnym repozytorium WordPressa. Pliki, wartości konfiguracyjne i instrukcje z tego projektu nie powinny być przenoszone do aktualnej integracji bazy danych SQLite; w każdym przypadku miarodajna jest dokumentacja konkretnie stosowanego projektu.

W przypadku istniejących stron internetowych często bezpieczniejszym rozwiązaniem jest pozostawienie MySQL lub MariaDB i osobne zbadanie wąskich gardeł. Buforowanie stron lub obiektów może ograniczyć liczbę zapytań do bazy danych, ale nie zastępuje migracji danych ani nie rozwiązuje kwestii kompatybilności związanej z integracją SQLite. Poniższy przegląd pomoże w klasyfikacji typowych zapytań w WordPressie oraz podejść do buforowania: Wydajność WordPressa i optymalizacja buforowania.

Ochrona bazy danych SQLite i tworzenie spójnych kopii zapasowych

W przypadku SQLite baza danych WordPressa znajduje się w jednym pliku na serwerze. Może ona zawierać między innymi treści, konta użytkowników, opcje i dane konfiguracyjne, dlatego należy ją chronić tak samo jak serwer bazy danych. Standardowy podkatalog o losowej nazwie, używany w wersji 3.1, jedynie utrudnia odgadnięcie ścieżki dostępu; nie zastępuje on jednak prawidłowo skonfigurowanych uprawnień do plików ani ograniczeń dostępu na serwerze WWW.

W ramach projektu zaleca się, DB_PATH jako ścieżkę bezwzględną poza katalogiem głównym serwisu. PHP potrzebuje tam uprawnień do zapisu, podczas gdy serwer WWW nie może bezpośrednio udostępniać pliku bazy danych. Takie rozdzielenie zmniejsza ryzyko, że błędna konfiguracja w katalogu dostępnym publicznie spowoduje udostępnienie tego pliku. Wdrożenie, zarządzanie uprawnieniami i tworzenie kopii zapasowych muszą wyraźnie uwzględniać wybraną lokalizację.

W przypadku kopii zapasowych, począwszy od linii wydawniczej 3.1, kluczowe znaczenie ma to, aby nie wprowadzać na stałe historycznych nazw plików ani domyślnej ścieżki. Wtyczka może uzyskać rzeczywistą ścieżkę poprzez DB_PATH udostępnić w czasie wykonywania; narzędzia do tworzenia kopii zapasowych, migracji i przywracania danych muszą zatem ustalić tę ścieżkę po załadowaniu WordPressa. Przed wdrożeniem należy przeprowadzić przywracanie danych w oddzielnym środowisku oraz udokumentować niezbędną ścieżkę, konfigurację i kolejne kroki.

Od wersji 3.0 wtyczki integracja domyślnie korzysta z trybu WAL. W tym trybie, oprócz głównej bazy danych, mogą być tworzone pliki pomocnicze o rozszerzeniach -wal oraz -shm powstać. Dlatego należy wyraźnie sprawdzić, czy używane narzędzie do tworzenia kopii zapasowych obsługuje tryb WAL działającej bazy danych SQLite i uwzględnia te elementy. Bez zatwierdzenia przez takie narzędzie samo skopiowanie pliku głównego nie pozwala na uzyskanie spójnej kopii zapasowej.

Wymagana przez wtyczkę minimalna wersja SQLite 3.37.0 określa techniczne minimum integracji. W celu zapewnienia prawidłowego działania należy dodatkowo śledzić, której wersji SQLite faktycznie używa PHP, oraz włączać poprawki bezpieczeństwa i błędów stosowanych pakietów PHP i SQLite do regularnego procesu aktualizacji. Jednak bez odpowiedniego źródła w istniejącym zbiorze źródeł nie można na tej podstawie sformułować wiarygodnych zaleceń dotyczących poszczególnych nowszych wersji SQLite lub konkretnych backportów.

Narzędzi do eksportu i tworzenia kopii zapasowych nie należy stosować wyłącznie dlatego, że są one znane z instalacji MySQL lub MariaDB. W przypadku konkretnego narzędzia sprawdź, czy obsługuje ono bazę danych SQLite w aktualnej DB_PATH oraz obsługiwany w skonfigurowanym trybie dziennika. Następnie przeprowadź przywracanie w przeznaczonym środowisku hostingowym i sprawdź, czy ścieżka do bazy danych, niezbędne elementy bazy danych oraz konfiguracja WordPressa zostały w pełni zsynchronizowane.

Rozpoznawanie konfliktów i ich celowa analiza

Wdrożenie należy najpierw przeprowadzić w środowisku testowym lub próbnym, a nie w ramach pierwszego wdrożenia produkcyjnego. Przed instalacją należy zarejestrować istniejące pliki w wp-content/db.php a także wtyczki, wtyczki MU oraz niestandardowe rozszerzenia wykorzystujące bezpośrednio bazę danych MySQL. Druga wtyczka typu „drop-in” dla bazy danych nie może działać równolegle; proces konfiguracji integracji sprawdza zatem, czy nie występują takie kolizje.

Następnie sprawdź konkretne procesy, a nie tylko stronę główną: logowanie i administrację, tworzenie treści, wyszukiwanie, formularze, zaplanowane zadania, import i eksport, a także tworzenie kopii zapasowych i przywracanie danych. Powtórz testy po aktualizacjach wtyczek i WordPressa. Warstwa integracyjna przetwarza składnię MySQL dla SQLite, jednak opisana w projekcie obsługa nie zastępuje sprawdzenia własnych zapytań lub rzadziej używanych funkcji danego rozszerzenia.

Częstymi błędami przy urządzaniu wnętrz są brak pdo_sqlite odpowiednio pdo lub niewystarczające uprawnienia do zapisu w katalogu bazy danych. Równie problematyczne jest założenie, że aktywacja przejmuje zawartość istniejącej instalacji MySQL lub MariaDB: tworzy ona oddzielną bazę danych SQLite, a nie powoduje automatycznej migracji danych. Również nowa wartość DB_PATH nie powoduje przeniesienia istniejącego pliku, lecz wskazuje na inną lokalizację.

Jeśli podczas obciążenia występują opóźnienia, należy najpierw sprawdzić, które operacje są wykonywane jednocześnie w trybie zapisu: na przykład zamówienia, przetwarzanie formularzy, żądania REST lub zadania w tle. SQLite pozwala na jednoczesny dostęp wielu czytelników, ale operacje zapisu w pliku bazy danych są wykonywane sekwencyjnie; ponadto wiele serwerów WWW zwiększa wymagania wobec architektury bazy danych. Nie można tego porównać z mechanizmami blokowania stosowanymi w MySQL-InnoDB. W analizie przyczyn występujących w tradycyjnych bazach danych WordPress pomocny jest artykuł na temat jednoczesne dostępy do bazy danych i blokady.

Wybór odpowiedniej strategii dotyczącej baz danych

SQLite sprawdza się w przypadku WordPressa, jeśli strona działa na pojedynczym systemie, jest głównie przeglądana, a liczba jednoczesnych zmian jest ograniczona i znana. Rozwiązanie to lepiej nadaje się do lokalnego programowania, stron demonstracyjnych lub niewielkich serwisów redakcyjnych niż do aplikacji o dużej liczbie transakcji. Warunkiem pozostaje potwierdzona kompatybilność faktycznie używanego motywu, wtyczek, narzędzi do importu oraz wszystkich własnych operacji na bazie danych.

W przypadku wdrożeń rozproszonych, wielu serwerów WWW lub operacji zapisu wykonywanych w krótkim odstępie czasu pozostają MySQL lub MariaDB bardziej odpowiednia strategia bazodanowa. Dotyczy to w szczególności sklepów internetowych obsługujących zamówienia, systemów rezerwacyjnych i sprzedaży biletów, funkcji społecznościowych oraz zautomatyzowanych interfejsów generujących dużą liczbę żądań zapisu. Decydujące znaczenie ma nie tyle ogólna liczba odwiedzających, co to, czy niezależne procesy muszą jednocześnie modyfikować tę samą bazę danych. W przypadku bezpośredniego, równoczesnego dostępu do bazy danych z wielu hostów za pośrednictwem sieci SQLite zasadniczo zaleca stosowanie modelu klient-serwer.

W przypadku istniejącej strony internetowej zmiana platformy nie oznacza automatycznie projektu związanego z poprawą wydajności. Buforowanie obiektowe lub stronicowe może ograniczyć liczbę zapytań do bazy danych i obciążenie PHP bez konieczności zastępowania MySQL lub MariaDB. Buforowanie i SQLite spełniają zatem różne zadania: pierwsze z nich ogranicza powtarzające się operacje przetwarzania, drugie zmienia model przechowywania danych i model działania bazy danych. Oficjalne wymagania WordPressa nadal wymieniają MariaDB lub MySQL jako standardowe wymagania dotyczące bazy danych.

Przed zatwierdzeniem kontrola typu „Go/No-Go” powinna obejmować co najmniej następujące kwestie:

• Architektura: Czy WordPress może działać w sposób ciągły na jednym serwerze bez konieczności, aby wiele hostów otwierało ten sam plik SQLite bezpośrednio za pośrednictwem sieciowego systemu plików?
• Wzory zapisu: Czy równoległe zamówienia, księgowania, formularze oraz operacje zapisu REST lub AJAX są ograniczone i sprawdzane w oddzielnym środowisku?
• Zgodność: Czy motyw, wtyczki, wtyczki MU i własne zapytania SQL działają w instancji testowej?
• Drop-ins: Czy plik wp-content/db.php nie powoduje konfliktów z rozwiązaniami bazodanowymi lub buforującymi?
• Migracja: Czy jest jasno udokumentowane, że podczas aktywacji nie są przenoszone żadne dane z MySQL lub MariaDB?
• Czas działania: Czy biblioteka SQLite załadowana przez PHP spełnia wymagania dotyczące minimalnej wersji wtyczki oraz czy aktualizacje PHP, SQLite i wtyczki są uwzględnione w procesie konserwacji?
• Kopia zapasowa: Czy kopia zapasowa określa aktualną ścieżkę DB_PATH, czy obsługuje stosowany tryb dziennika oraz czy przywrócenie danych zostało przeprowadzone i udokumentowane w oddzielnym środowisku?
• Działanie: Czy aktualizacje wtyczki i WordPressa są zabezpieczone za pomocą powtarzalnej procedury testowej?