SQLite comme base de données WordPress : état d'avancement, limites et cas d'utilisation

Bien comprendre WordPress et SQLite

WordPress ne prend actuellement pas en charge SQLite en tant que plateforme de base de données sélectionnable par défaut dans le noyau. La configuration système officielle continue de mentionner MySQL ou MariaDB ; SQLite ne fait pas partie des prérequis standard d'une installation WordPress. Les utilisateurs qui exploitent WordPress avec SQLite ne se contentent donc pas de modifier un paramètre du cœur, mais ajoutent à WordPress une couche d'intégration spécifique.

Cette couche est fournie par le plugin Intégration d'une base de données SQLite Prêt. Il est disponible dans le répertoire des plugins de WordPress.org et est développé en tant que plugin communautaire ou « feature plugin ». Son objectif est de tester une implémentation SQLite et de recueillir des retours d'expérience en vue d'une éventuelle intégration ultérieure dans le cœur du logiciel. Sa présence dans l’écosystème WordPress.org ne signifie donc pas qu’il soit intégré de manière permanente à une installation WordPress standard.

Cette initiative remonte à un certain temps : en septembre 2022, une proposition visant à prendre officiellement en charge SQLite à long terme a été présentée publiquement au sein de l'équipe WordPress Core. Depuis janvier 2023, l'implémentation est disponible sous forme de plugin autonome ; le lien vers Performance Lab qui figurait à l'époque décrivait une étape de développement, et non la procédure standard actuelle pour tous les sites WordPress.

Pour une classification fiable, c’est le numéro de version qui fait foi. À la date de la recherche, le 18 octobre 2026, la version v3.1.0 du 8 octobre 2026 est la version stable. Les informations issues de la branche de développement ne doivent pas être considérées d’emblée comme des caractéristiques de cette version stable. À l’inverse, il serait erroné d’assimiler le plugin actif à une validation générale pour une utilisation en production dans tous les cas d’utilisation de WordPress, uniquement pour cette raison.

On ne peut donc répondre à la question du lecteur par l'affirmative que dans une certaine mesure : SQLite peut s'avérer utile pour des installations clairement délimitées, par exemple pour le développement, les démos ou les petits sites web hébergés sur un seul serveur et dont les modifications restent gérables. Pour les installations distribuées, à forte intensité d'écriture ou critiques pour l'activité, MySQL ou MariaDB restent la base officiellement prise en charge et généralement la plus adaptée. L'architecture, les modèles d'écriture et la compatibilité effective de la pile utilisée sont déterminants.

Base de données de fichiers, compatibilité « drop-in » et compatibilité SQL

La différence fondamentale réside dans le modèle de stockage. SQLite est une base de données de fichiers: Les données sont stockées localement dans un fichier de base de données sur le système de fichiers. MySQL et MariaDB, en revanche, fonctionnent comme des services de base de données autonomes avec lesquels WordPress communique via une connexion au serveur. SQLite peut donc permettre un environnement plus léger, mais nécessite un emplacement de stockage local adapté et des droits d'accès appropriés.

Le cœur de WordPress, les thèmes et la plupart des extensions utilisent l'interface bien connue pour accéder à la base de données wpdb. Le plugin remplace la couche de base de données habituelle via le « drop-in » wp-content/db.php. Ce module « drop-in » intercepte les requêtes et fait le lien entre l'environnement WordPress, habituellement basé sur MySQL, et SQLite. Ainsi, l'interface utilisateur reste la même pour de nombreux composants, même si la base de données sous-jacente change.

La couche de médiation est l'élément clé qui se cache derrière l'affirmation simplifiée selon laquelle „ WordPress fonctionne avec SQLite “. WordPress ne génère pas automatiquement du code SQL spécifique à SQLite. La documentation du projet dans la branche de développement trunk décrit un analyseur MySQL qui reproduit la grammaire SQL et les fonctions nécessaires pour SQLite. Cela explique l'approche de développement, mais ne constitue ni un engagement concernant une version stable, ni une garantie que chaque requête ou extension MySQL spécifique soit compatible sans adaptation.

Tu dois examiner avec une attention particulière les extensions qui génèrent directement du code SQL, qui nécessitent des fonctions de base de données ou qui gèrent leurs propres tables de manière inhabituelle. Cela concerne également les outils d'importation, les outils de reporting et les scripts de maintenance. Un thème ou un plugin peut fonctionner normalement, mais échouer lors d’une opération d’administration peu courante, d’une mise à jour ou d’une requête spécifique en raison d’une particularité de MySQL non prise en charge.

Les différences au niveau du schéma, des métadonnées et des requêtes types restent pertinentes pour l'évaluation. La vue d'ensemble interne concernant Les tables de la base de données WordPress et leurs performances permet d'identifier les extensions faisant un usage intensif de la base de données et les tables personnalisées comme points de contrôle potentiels. Intégration de SQLite Cela ne remplace ni l'analyse de ces requêtes, ni la responsabilité de tester les modifications apportées en dehors de l'interface standard de WordPress avant leur mise en production.

Quand l'utilisation de SQLite est techniquement justifiée

Une décision judicieuse ne repose pas sur un nombre global de visiteurs. Ce qui est déterminant, c'est la Concours d'écriture: SQLite autorise plusieurs lecteurs en parallèle, mais une seule opération d'écriture peut avoir lieu à la fois par fichier de base de données. Si plusieurs modifications coïncident dans le temps, les opérations d'écriture suivantes doivent attendre. La documentation SQLite recommande d'utiliser une base de données client-serveur en cas de nombreux clients indépendants, de plusieurs ordinateurs ou de nombreuses opérations d'écriture simultanées.

Les domaines d'application clairement identifiables sont le développement local, les formations, les démonstrations et les environnements de test éphémères. Dans ces cas-là, il n'est pas nécessaire de configurer un service MySQL ou MariaDB distinct, tandis que la pile de plugins et de thèmes peut être testée de manière contrôlée. Un petit site web hébergé sur un seul serveur peut également convenir s’il est principalement consulté et si les modifications rédactionnelles sont rares et ne se concentrent pas sur une période donnée.

Un site web d'entreprise épuré, un blog personnel ou une page de campagne ne sont toutefois pas automatiquement adaptés. Les formulaires de contact, les espaces membres, les intégrations de newsletters ou les points de terminaison programmés individuellement peuvent déclencher des opérations d'écriture supplémentaires. Vérifie donc non seulement les consultations de pages, mais aussi les mises à jour d'options, les soumissions de formulaires, les tâches planifiées ainsi que les modifications de données effectuées par des plugins et des interfaces externes.

Pour les boutiques en ligne traitant des commandes, les systèmes de réservation et de billetterie, les communautés actives ou les applications impliquant de nombreuses opérations d'écriture AJAX et REST, cette limitation est généralement plus importante. Dans ces cas-là, plusieurs utilisateurs peuvent enregistrer des commandes, modifier des disponibilités ou créer des contributions presque simultanément. La présence de plusieurs serveurs web derrière un équilibreur de charge n'est pas non plus compatible avec l'approche de gestion de fichiers en local que SQLite présuppose pour ce cas d'utilisation.

La mise en cache remplit une fonction différente de celle de SQLite. La mise en cache de pages ou d'objets peut réduire les accès en lecture récurrents et, par conséquent, les requêtes à la base de données ; elle ne transforme toutefois pas une application à forte intensité d'écriture en une installation SQLite à faible risque de conflit. À l'inverse, SQLite ne remplace pas un concept de mise en cache. Pour les sites web existants, le maintien de MySQL ou de MariaDB, associé à une mise en cache adaptée, peut donc constituer la solution la moins risquée, sans avoir à changer de plateforme de base de données.

Évaluer systématiquement des scénarios avec SQLite

Ce n'est pas le nombre de visiteurs qui détermine si SQLite convient à WordPress, mais l'interaction entre les opérations d'écriture, la configuration du serveur et les extensions. SQLite peut gérer des accès en lecture parallèles, mais ne peut pas exécuter en parallèle un nombre illimité d’opérations d’écriture sur le même fichier de base de données. C’est pourquoi un site web unique générant un grand nombre de pages vues n’est pas automatiquement inadapté, alors que des commandes ou des réservations déclenchées simultanément peuvent s’avérer critiques.

Ce tableau constitue une présélection, et non une validation définitive. En particulier pour le site web d’une petite entreprise, un formulaire CRM, un espace membre ou un service d’automatisation externe peuvent transformer une page peu mise à jour en un cas de charge d’écriture importante. À l’inverse, un blog comptant de nombreux lecteurs reste un candidat plausible si les commentaires, les formulaires et les modifications administratives restent gérables. Le plugin indique lui-même que l’adéquation dépend du trafic et de la charge d’écriture.

Le mode multisite est décrit dans la documentation du projet de la branche de développement comme un scénario pouvant être mis en place ; le référentiel contient d'ailleurs des tests spécifiques à cet effet. Cela n'implique toutefois pas une validation générale pour la mise en production sur de grands réseaux comptant de nombreux rédacteurs, sites ou intégrations. Considérez donc un réseau comme un cas de compatibilité à part entière et vérifiez les processus de gestion, de mise à jour et de contenu réellement utilisés.

L'étape pratique obligatoire consiste à tester la pile concrète dans un environnement isolé. Cela inclut le thème actif, tous les plugins en production, les plugins MU personnalisés, les importateurs, les formulaires, les points de terminaison REST ainsi que les outils de sauvegarde et de surveillance. Il ne suffit pas de vérifier si les pages se chargent : chaque extension comportant ses propres hypothèses SQL ou nécessitant des modifications fréquentes doit passer de manière fiable par la couche SQLite.

Mise en place et configuration sécurisée des chemins d'accès

Cette configuration convient à une nouvelle installation de test ou à une installation SQLite planifiée, mais pas comme solution de secours pour un environnement de production existant. Avant l'activation, PHP doit disposer de l'extension pdo_sqlite fournir une prise en charge PDO ; par ailleurs, le plugin nécessite SQLite à partir de la version 3.37.0. PHP doit disposer des droits d'écriture sur le répertoire de base de données sélectionné. La boîte de dialogue de configuration vérifie ces conditions et détecte également les modules de base de données existants susceptibles d'entrer en conflit.

La version minimale de SQLite indiquée correspond à une exigence technique du plugin, mais ne constitue pas une garantie générale pour tous les cas d'utilisation en production. Depuis la version 3.0 du plugin, Journalisation anticipée (Write-Ahead Logging) activée par défaut. Les administrateurs doivent donc vérifier quelle bibliothèque SQLite est effectivement chargée par le moteur PHP utilisé, et inclure les mises à jour des plugins, de PHP et de SQLite dans leurs contrôles de maintenance et de compatibilité.

Vérifie tout particulièrement wp-content/db.php. Ce fichier est le « drop-in » WordPress central pour la couche de base de données ; deux solutions ne peuvent pas l'utiliser simultanément. Si un module existe déjà à cet emplacement, par exemple pour une autre connexion à la base de données ou une solution de mise en cache, il faut vérifier avant l’installation quel composant il fournit et s’il est possible de le désinstaller proprement.

La version stable 3.1.0 utilise par défaut des sous-répertoires aux noms aléatoires sous wp-content/database/. L'emplacement déterminé est indiqué dans db-path.php consigné et transmis via DB_PATH mis à disposition. Les outils de sauvegarde et de migration ne doivent donc pas supposer l'existence d'un nom de fichier historique ou d'un chemin d'accès standard présupposé. Les anciennes constantes DB_DIR et DB_FILE sont signalées comme obsolètes dans la section 3.1 ; DB_PATH a la priorité.

Pour une nouvelle installation prévue, le projet recommande d'utiliser un chemin absolu situé en dehors du répertoire Web accessible au public. Le répertoire de destination doit être accessible en écriture pour le processus PHP. Le paramètre suivant doit figurer dans wp-config.php Il s'agit d'un exemple de configuration, et non d'instructions pour la migration ultérieure d'un site web déjà en ligne.

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

Avertissement : un nouveau DB_PATH ne déplace pas le fichier de base de données existant. Il sélectionne un autre emplacement de stockage. Si la valeur est modifiée sans préparation, WordPress risque donc d'utiliser une autre base de données ou une base de données vide. Prévoyez ensemble le chemin d'accès, les droits d'accès, la sauvegarde et un test de restauration avant la mise en production.

La structure aléatoire des répertoires dans la version 3.1 ne fait que réduire la prévisibilité du chemin d'accès par défaut. Elle ne remplace ni les droits d'accès au système de fichiers, ni un emplacement de stockage protégé de manière fiable contre toute divulgation publique. Le chemin recommandé, situé en dehors de la racine du site Web, est le plus sûr ; si un autre emplacement est choisi, l'accès du serveur Web à celui-ci doit être exclu de manière tout aussi fiable.

Pas de changement de base de données par activation

Dans le cas d'un site WordPress existant utilisant MySQL ou MariaDB, l'activation de l'intégration de la base de données SQLite ne constitue pas une migration. Le plugin crée une base de données SQLite distincte, initialement vide. Les articles, les utilisateurs, les options, les fichiers multimédias et les données des plugins provenant de l'ancienne base de données ne sont pas automatiquement transférés. Si l'intégration est désactivée ultérieurement, WordPress se reconnecte à l'ancienne base de données ; les modifications effectuées dans SQLite ne sont pas répercutées.

Cette séparation est utile pour les tests, mais indispensable pour les migrations en production. Quiconque souhaite réellement transférer des contenus vers une autre plateforme de base de données a besoin d’un plan de migration spécifique et traçable, comprenant le transfert des données, la vérification des jeux de caractères et des options, ainsi qu’un plan de secours. Le simple fait de basculer le « drop-in » ne peut pas remplacer ce processus.

Le terme bases de données distinctes Il faut prendre cette expression au sens littéral : pendant le fonctionnement de SQLite, les deux bases de données peuvent contenir des contenus différents. Un article test créé dans SQLite n'apparaîtra pas soudainement dans MySQL ou MariaDB après la désactivation. De même, un nouvel article créé dans MySQL restera invisible tant que WordPress utilisera le fichier SQLite comme source de données active.

Le référentiel wp-sqlite-db Se présente comme un projet autonome proposant un module de remplacement SQLite unique et renvoie à l'intégration SQLite d'origine. Il ne doit donc pas être assimilé au dépôt WordPress actuel. Les fichiers, les paramètres de configuration et les instructions issus de ce projet ne doivent pas être transférés vers l'intégration actuelle de la base de données SQLite ; c'est la documentation du projet concrètement utilisé qui fait foi dans chaque cas.

Pour les sites web existants, la décision la moins risquée consiste souvent à conserver MySQL ou MariaDB et à analyser séparément les goulots d'étranglement. La mise en cache des pages ou des objets peut réduire le nombre de requêtes à la base de données, mais ne remplace pas la migration des données et ne résout pas les problèmes de compatibilité liés à l'intégration de SQLite. Cet aperçu vous aidera à classer les requêtes WordPress typiques et à identifier les approches de mise en cache : Performances de WordPress et optimisation de la mise en cache.

Protéger une base de données SQLite et en effectuer des sauvegardes cohérentes

Avec SQLite, la base de données WordPress est stockée dans un fichier sur le serveur. Elle peut notamment contenir du contenu, des comptes utilisateurs, des options et des données de configuration ; elle doit donc être protégée comme un serveur de base de données. Un sous-répertoire par défaut portant un nom aléatoire, utilisé par la version 3.1, ne fait que compliquer la devinette du chemin d'accès ; il ne remplace en aucun cas des droits d'accès correctement configurés ni les restrictions d'accès du serveur web.

Le projet recommande de, DB_PATH à définir comme chemin absolu en dehors de la racine du site. PHP a besoin de droits d'écriture à cet emplacement, tandis que le serveur web ne doit pas servir directement le fichier de base de données. Cette séparation réduit le risque qu'une erreur de configuration au sein du répertoire accessible au public rende le fichier accessible. Le déploiement, la gestion des droits d’accès et la sauvegarde doivent expressément tenir compte de l’emplacement de stockage choisi.

Pour les sauvegardes, depuis la version 3.1, il est essentiel de ne pas définir de manière fixe de nom de fichier historique ni de chemin d'accès standard présumé. Le plugin peut déterminer le chemin d'accès réel via DB_PATH le rendre disponible lors de l'exécution ; les outils de sauvegarde, de migration et de restauration doivent donc le détecter après le chargement de WordPress. Avant toute mise en production, tu devrais effectuer la restauration dans un environnement isolé et documenter le chemin d'accès, la configuration et les étapes nécessaires à cette opération.

Depuis la version 3.0 du plugin, l'intégration utilise par défaut le mode WAL. Dans ce cadre, outre la base de données principale, des fichiers associés portant les extensions -wal et -shm peuvent survenir. Vérifiez donc expressément si l'outil de sauvegarde utilisé prend en charge le mode WAL de la base de données SQLite en cours d'exécution et tient compte de ces éléments. Sans une telle validation de l'outil, la simple copie du fichier principal ne permet pas d'obtenir une sauvegarde cohérente.

La version minimale SQLite 3.37.0 indiquée par le plugin correspond à la limite technique inférieure de l'intégration. Pour le fonctionnement, tu dois également vérifier quelle version de SQLite PHP utilise réellement et intégrer les correctifs de sécurité et les corrections de bogues des paquets PHP et SQLite utilisés dans le processus de mise à jour régulier. Toutefois, en l'absence d'une source correspondante dans le répertoire des sources existantes, il n'est pas possible d'en déduire une recommandation fiable concernant des versions supérieures de SQLite ou des backports spécifiques.

Les outils d'exportation et de sauvegarde ne doivent pas être utilisés uniquement parce qu'ils sont courants dans les installations MySQL ou MariaDB. Vérifie, pour l'outil en question, s'il prend en charge la base de données SQLite dans la version actuelle DB_PATH et pris en charge dans le mode journal configuré. Effectuez ensuite une restauration dans l'environnement d'hébergement prévu et vérifiez si le chemin d'accès à la base de données, les composants nécessaires de la base de données et la configuration de WordPress sont bien tous restaurés.

Identifier les conflits et les analyser de manière ciblée

La migration doit d'abord être effectuée sur un environnement de préproduction ou de test, et non lors du premier déploiement en production. Avant l'installation, répertoriez les fichiers existants sous wp-content/db.php ainsi que les plugins, les plugins MU et les extensions personnalisées qui utilisent directement MySQL. Une deuxième base de données « drop-in » ne peut pas fonctionner en parallèle ; le processus de configuration de l'intégration vérifie donc l'absence de tels conflits.

Testez ensuite des processus concrets plutôt que de vous limiter à la page d'accueil : connexion et administration, création de contenu, recherche, formulaires, tâches planifiées, importation et exportation, ainsi que sauvegarde et restauration. Répétez les tests après chaque mise à jour des plugins et de WordPress. La couche d'intégration traite la syntaxe MySQL pour SQLite, mais la prise en charge décrite dans le projet ne remplace pas la vérification de vos propres requêtes ou des fonctions moins courantes d'une extension.

Parmi les erreurs courantes de configuration, on peut citer l'absence de pdo_sqlite ou pdo ou des droits d'écriture insuffisants pour le répertoire de la base de données. Il est tout aussi problématique de supposer que l'activation reprend le contenu d'une installation MySQL ou MariaDB existante : elle crée une base de données SQLite distincte, et ne procède pas automatiquement à une migration des données. De même, un nouveau DB_PATH ne déplace pas un fichier existant, mais pointe vers un autre emplacement.

Si des temps d'attente apparaissent sous charge, commencez par identifier les actions qui effectuent des écritures simultanées : par exemple, les commandes, le traitement des formulaires, les requêtes REST ou les tâches en arrière-plan. SQLite autorise plusieurs lecteurs, mais sérialise les opérations d'écriture par fichier de base de données ; la présence de plusieurs serveurs web accroît en outre les exigences imposées à l'architecture de la base de données. Cela ne doit pas être assimilé aux mécanismes de verrouillage de MySQL-InnoDB. Pour l'analyse des causes dans le cas des bases de données WordPress classiques, l'article consacré à accès simultanés à la base de données et verrous.

Choisir la stratégie de base de données adaptée

SQLite est une solution acceptable pour WordPress lorsque le site web fonctionne sur un seul serveur, qu'il est principalement consulté en lecture et que les modifications simultanées sont limitées et connues. Il convient donc davantage au développement local, aux démos ou aux petits sites web éditoriaux qu'aux applications impliquant de nombreuses transactions. La condition préalable reste la compatibilité avérée du thème, des plugins, des outils d’importation et de tous les accès à la base de données propres au site effectivement utilisés.

Dans le cas de déploiements distribués, de plusieurs serveurs Web ou d'opérations d'écriture concentrées dans le temps, il reste MySQL ou MariaDB la stratégie de base de données la plus adaptée. Cela concerne en particulier les boutiques en ligne traitant des commandes, les systèmes de réservation et de billetterie, les fonctionnalités communautaires et les interfaces automatisées générant de nombreuses requêtes d'écriture. Ce n’est pas le nombre global de visiteurs qui est déterminant, mais le fait que des processus indépendants doivent modifier simultanément la même base de données. Pour un accès direct et simultané à la base de données depuis plusieurs hôtes via un réseau, SQLite recommande en principe un système client-serveur.

Pour un site web existant, un changement de plateforme ne se traduit d'ailleurs pas automatiquement par un projet d'optimisation des performances. La mise en cache par objet ou par page peut réduire les requêtes à la base de données et la charge de travail PHP sans pour autant remplacer MySQL ou MariaDB. La mise en cache et SQLite remplissent ainsi des fonctions différentes : la première réduit les opérations de traitement récurrentes, tandis que la seconde modifie le modèle de stockage et de fonctionnement de la base de données. Les exigences officielles de WordPress continuent de mentionner MariaDB ou MySQL comme prérequis standard en matière de base de données.

Avant la validation, un contrôle « Go/No-Go » devrait au moins porter sur les points suivants :

• Architecture : WordPress peut-il fonctionner en permanence sur un seul serveur sans que plusieurs hôtes aient besoin d'ouvrir directement le même fichier SQLite via un système de fichiers en réseau ?
• Modèles d'écriture : les commandes, écritures comptables, formulaires et opérations d'écriture REST ou AJAX parallèles sont-ils limités et testés dans un environnement isolé ?
• Compatibilité : le thème, les plugins, les plugins MU et les requêtes SQL personnalisées fonctionnent-ils dans l'instance de test ?
• Drop-ins : le fichier wp-content/db.php ne présente-t-il aucun conflit avec les solutions de base de données ou de mise en cache ?
• Migration : est-il clairement indiqué que l'activation ne reprend aucun contenu provenant de MySQL ou de MariaDB ?
• Durée de vie : la bibliothèque SQLite chargée par PHP est-elle conforme à la version minimale requise pour le plugin, et les mises à jour de PHP, de SQLite et du plugin sont-elles intégrées au processus de maintenance ?
• Sauvegarde : la sauvegarde détermine-t-elle le DB_PATH actuel, prend-elle en charge le mode de journalisation utilisé, et une restauration a-t-elle été effectuée et documentée dans un environnement isolé ?
• Exploitation : les mises à jour du plugin et de WordPress sont-elles sécurisées grâce à une procédure de test reproductible ?