WordPress et SQLite en 2026 : état réel, tests et limites

Mis à jour le 1er novembre 2026. Article réécrit pour la version 3.1.2 de SQLite Database Integration (28 octobre 2026) : nouveau pilote de la version 3.0, emplacement de la base, absence de migration, et deux tests réalisés sur notre poste (copie d’une base en mode WAL, écritures concurrentes).

Faire tourner WordPress sans serveur MySQL ni MariaDB, avec une base contenue dans un fichier SQLite, est possible grâce à une extension officielle du projet WordPress. En 2026, le sujet a changé de nature : le pilote a été réécrit, il émule bien mieux MySQL, mais il reste une extension de test, et non une fonction du cœur. Ce guide fait le point sur ce qui fonctionne, ce qui casse, et la façon d’exploiter ce montage sur une petite instance.

Où en est SQLite dans WordPress

WordPress 7.1 ne sait toujours pas utiliser SQLite seul : il faut cette extension, qui remplace la couche d’accès à la base par une implémentation SQLite. WordPress continue d’utiliser l’API wpdb ; l’extension traduit et émule les requêtes MySQL.

Ce qu’a changé la version 3.0

La version 3.0.0, publiée en août 2026, a remplacé l’ancien traducteur par un pilote reconstruit : un analyseur lexical et syntaxique de la grammaire MySQL écrit en PHP, et une couche d’émulation. Il gère les jointures complexes, les sous-requêtes, les CTE et les unions, émule les tables INFORMATION_SCHEMA et les commandes SHOW et DESCRIBE, et reproduit de plus près les types, valeurs par défaut, modes SQL et transactions de MySQL. L’ancien pilote a été supprimé.

Ce pilote vient d’un long travail public. En juin 2025, l’équipe de WordPress Playground indiquait qu’il faisait passer plus de 99 % des tests PHPUnit du cœur et analysait sans erreur une suite d’environ 70 000 requêtes MySQL. Il fait fonctionner le site de WordPress Playground.

La version 3.0 a introduit des changements cassants pour les intégrations : le mode WAL devient la valeur par défaut, la constante DB_NAME doit être définie et non vide, plusieurs constantes et classes sont renommées. La 3.1.0 a ensuite placé la base à un emplacement aléatoire, avec la constante DB_PATH.

Installer sans se piéger

L’écran d’installation de l’extension vérifie la présence de PDO SQLite, le droit d’écriture sur wp-content et l’absence d’un autre fichier de remplacement de la base. Vérifiez avant tout la version de SQLite vue par PHP :

php -r "echo (new PDO('sqlite::memory:'))->query('select sqlite_version()')->fetchColumn(), PHP_EOL;"

Sur notre poste, PHP 8.3.30 renvoie 3.40.0, au-dessus du minimum de 3.37.0. Les versions 3.27 à 3.36 ne sont acceptées qu’avec une constante d’activation explicite, à éviter en production.

Trois points à connaître avant d’activer :

• Aucune migration. Activer SQLite crée une base séparée et vide. Le contenu MySQL existant n’est pas copié. Désactiver l’extension reconnecte l’ancienne base, et ce qui a été créé sous SQLite n’y est pas reporté.
• Emplacement de la base. Par défaut, un chemin aléatoire sous wp-content/database/, noté dans db-path.php. La FAQ recommande de définir DB_PATH avec un chemin absolu hors de la racine web. Les chemins relatifs sont refusés, et modifier DB_PATH ne déplace pas une base existante.
• Fichiers annexes. En mode WAL, la base est accompagnée de fichiers -wal et -shm. Ils font partie de la base.

// wp-config.php, avant la ligne « That's all, stop editing! »
define( 'DB_PATH', '/var/lib/wordpress/monsite/base.sqlite' );

Le répertoire doit être accessible en écriture par l’utilisateur de PHP. Le chemin ci-dessus est un exemple : adaptez-le à votre serveur.

Test n° 1 : la copie d’un fichier en cours d’utilisation

Nous avons créé une base SQLite en mode WAL avec deux lignes, puis un script PHP y a ajouté 1 000 lignes en gardant sa connexion ouverte, comme le ferait un site actif. Pendant ce temps, nous avons comparé deux sauvegardes :

Les 1 000 lignes récentes se trouvaient encore dans le fichier -wal. Une sauvegarde qui copie le seul fichier principal, comme le font beaucoup d’outils de sauvegarde de fichiers, perd donc les écritures récentes sans aucun message d’erreur. Utilisez l’API de sauvegarde de SQLite :

#!/bin/sh
BASE=/var/lib/wordpress/monsite/base.sqlite
DEST=/var/backups/wordpress/base-$(date +%F).sqlite
sqlite3 "$BASE" ".backup '$DEST'"
sqlite3 "$DEST" "PRAGMA integrity_check;"

Complétez avec wp-content/uploads, les thèmes et les extensions, et testez une restauration sur une instance séparée. Vérifiez aussi que votre extension de sauvegarde sait lire une base SQLite : une extension qui appelle mysqldump ne trouvera pas de serveur MySQL.

Test n° 2 : deux écritures en même temps

SQLite accepte de nombreuses lectures simultanées, mais une seule écriture à la fois. Nous avons ouvert une transaction d’écriture de six secondes dans un premier processus PHP, puis tenté une insertion depuis un second :

Le mode WAL ne supprime pas cette règle ; il évite seulement que les lectures bloquent l’écriture. Tout dépend donc du délai d’attente et de la durée des transactions. La version 3.1.2 de l’extension permet de régler ce délai avec la constante SQLITE_BUSY_TIMEOUT. Un délai plus long transforme les erreurs en attentes, mais ces attentes s’additionnent si les écritures sont nombreuses.

Les écritures fréquentes ne viennent pas toujours des visiteurs : sessions, statistiques maison, journaux d’activité, files d’envoi de courriels et tâches planifiées écrivent aussi en base.

Compatibilité des extensions

Le nouveau pilote couvre bien mieux le SQL de MySQL, mais une extension peut encore poser problème si elle :

• exécute du SQL écrit à la main, avec des fonctions propres à MySQL ;
• se connecte directement à MySQL sans passer par wpdb ;
• appelle des outils externes comme mysqldump ou mysql ;
• suppose des comportements d’index ou de verrouillage propres à InnoDB.

Le journal des modifications montre que des corrections continuent d’arriver chaque mois : arithmétique INTERVAL, FOUND_ROWS(), tables temporaires, ALTER TABLE (versions 3.1.1 et 3.1.2). Testez donc chaque extension métier sur une préproduction, en priorité les formulaires, la recherche, les exports et tout ce qui touche aux comptes clients. L’extension affiche ses informations dans Santé du site et prend en charge Query Monitor, pratique pour repérer une requête en échec.

Pour quels sites ?

Sur une micro-instance, le gain est réel mais limité : pas de processus MySQL qui réserve de la mémoire en permanence, une installation plus simple. En contrepartie, vous perdez les outils d’exploitation d’un serveur de base (réplication, sauvegardes à chaud éprouvées, outils de diagnostic). Pour choisir l’instance elle-même, voir notre comparatif des VPS à petit prix et notre comparatif d’hébergeurs.

Mettre à jour sans surprise

Le cœur, l’extension et ses constantes évoluent séparément, et la 3.0 comme la 3.1.0 contenaient des changements cassants. Avant chaque mise à jour de l’extension ou de WordPress : sauvegarde par .backup, mise à jour en préproduction, parcours de test, puis production. La méthode générale est détaillée dans notre guide de mise à jour sécurisée sur VPS.

Pour revenir vers MySQL ou MariaDB, il n’existe pas d’outil de bascule intégré. Les nouvelles tables utilisent par défaut l’interclassement utf8mb4_unicode_520_ci, choisi pour faciliter l’export vers MariaDB, mais une migration reste un projet : export, import sur une instance vierge, comparaison des contenus, des utilisateurs et des réglages, fenêtre de maintenance.

Questions fréquentes

SQLite fait-il partie de WordPress 7.1 ?

Non. Il faut l’extension SQLite Database Integration. Son objectif affiché est une intégration future au cœur, sans date annoncée.

Puis-je convertir mon site MySQL existant en activant l’extension ?

Non. L’activation crée une base vide et séparée. Il faut importer le contenu par un autre moyen, puis vérifier le résultat sur une préproduction.

Une sauvegarde de fichiers suffit-elle ?

Pas si elle copie le fichier de base pendant que le site écrit : notre test a perdu 1 000 lignes de cette façon. Utilisez .backup ou VACUUM INTO, puis contrôlez l’intégrité de la copie.

SQLite convient-il à une boutique WooCommerce ?

Nous le déconseillons. Commandes, paniers, stocks et sessions écrivent souvent en même temps, et une erreur database is locked au moment d’un paiement a un coût direct. Restez sur MySQL ou MariaDB.

Sources

• WordPress.org, extension SQLite Database Integration (version 3.1.2, description, FAQ et journal des modifications, relevés le 1er novembre 2026) : https://wordpress.org/plugins/sqlite-database-integration/
• GitHub, WordPress/sqlite-database-integration, notes des versions 3.0.0 à 3.1.2 : https://github.com/WordPress/sqlite-database-integration/releases
• WordPress Playground, Introducing a new SQLite driver for WordPress (13 juin 2025) : https://make.wordpress.org/playground/2025/06/13/introducing-a-new-sqlite-driver-for-wordpress/
• Tests réalisés le 1er novembre 2026 sur notre poste : PHP 8.3.30 (PDO SQLite, SQLite 3.40.0) et SQLite 3.47.2 en ligne de commande.

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →