SQLite como base de datos de WordPress: estado actual, limitaciones y casos de uso

Entender bien WordPress y SQLite

Actualmente, WordPress no admite SQLite como plataforma de base de datos seleccionable de forma habitual en el núcleo. Los requisitos del sistema oficiales siguen indicando MySQL o MariaDB; SQLite no forma parte de los requisitos estándar de una instalación de WordPress. Por lo tanto, quien utilice WordPress con SQLite no se limita a cambiar una configuración del núcleo, sino que añade a WordPress una capa de integración propia.

Esta capa la proporciona el complemento Integración con la base de datos SQLite Listo. Está disponible en el directorio de plugins de WordPress.org y se está desarrollando como un plugin de la comunidad o de funciones. Su objetivo es probar una implementación de SQLite y recabar opiniones de cara a una posible integración posterior en el núcleo. Por lo tanto, su presencia en el ecosistema de WordPress.org no supone su inclusión como parte integrante de una instalación normal de WordPress.

La iniciativa lleva tiempo gestándose: en septiembre de 2022 se propuso públicamente en el equipo del núcleo de WordPress que se diera soporte oficial a SQLite a largo plazo. Desde enero de 2023, la implementación se puede descargar como un plugin independiente; el enlace a Performance Lab que existía entonces describe una etapa del desarrollo, no la vía estándar actual para cualquier sitio web de WordPress.

Para una clasificación fiable, lo que cuenta es el número de versión. A fecha de la consulta, el 18 de octubre de 2026, la versión v3.1.0, del 8 de octubre de 2026, es la versión estable. Las características de la rama de desarrollo no deben considerarse automáticamente como características de esta versión estable. Por el contrario, sería erróneo equiparar el plugin activo con una autorización general de uso en producción para cualquier caso de uso de WordPress solo por ese motivo.

Por lo tanto, la respuesta a la pregunta del lector solo puede ser «sí» hasta cierto punto: SQLite puede resultar útil para instalaciones claramente delimitadas, como por ejemplo para desarrollo, demostraciones o pequeños sitios web con un único servidor y cambios manejables. Para instalaciones distribuidas, con un uso intensivo de escritura o críticas para el negocio, MySQL o MariaDB siguen siendo la base con soporte oficial y, en la mayoría de los casos, la más adecuada. Los factores decisivos son la arquitectura, los patrones de escritura y la compatibilidad real de la pila utilizada.

Base de datos de archivos, compatibilidad «drop-in» y con SQL

La diferencia fundamental radica en el modelo de almacenamiento. SQLite es una Base de datos de archivos: Los datos se almacenan localmente en un archivo de base de datos en el sistema de archivos. MySQL y MariaDB, por su parte, funcionan como servicios de base de datos independientes con los que WordPress se comunica a través de una conexión al servidor. Por lo tanto, SQLite puede ofrecer un entorno más ligero, pero requiere una ubicación de almacenamiento local adecuada y los permisos de archivo correspondientes.

El núcleo de WordPress, los temas y la mayoría de las extensiones utilizan la conocida interfaz para acceder a la base de datos wpdb. El complemento sustituye la capa de base de datos habitual mediante el método «drop-in» wp-content/db.php. Este «drop-in» intercepta las consultas y actúa como intermediario entre el entorno de WordPress, orientado a MySQL, y SQLite. De este modo, la interfaz de la aplicación sigue siendo la misma para muchos componentes, aunque cambie la base de datos subyacente.

La capa de mediación es el punto clave que se esconde tras la afirmación simplificada de que „WordPress funciona con SQLite“. WordPress no genera automáticamente código SQL específico para SQLite. La documentación del proyecto en la rama de desarrollo trunk Describe un analizador sintáctico de MySQL que reproduce la sintaxis SQL y las funciones necesarias para SQLite. Esto explica el enfoque de desarrollo, pero no supone ni un compromiso de versión estable ni una garantía de que cada consulta o extensión concreta de MySQL sea compatible sin necesidad de adaptaciones.

Debes revisar con especial cuidado los complementos que generan código SQL directamente, que requieren funciones de la base de datos o que gestionan sus propias tablas de forma inusual. Esto se aplica también a los importadores, las herramientas de generación de informes y los scripts de mantenimiento. Un tema o un plugin puede funcionar correctamente en condiciones normales y, sin embargo, fallar durante una operación administrativa poco habitual, una actualización o una consulta específica debido a una particularidad de MySQL que no se haya tenido en cuenta.

Las diferencias en cuanto al esquema, los metadatos y las consultas típicas siguen siendo relevantes para la evaluación. La visión general interna sobre Las tablas de la base de datos de WordPress y su rendimiento Ayuda a identificar las ampliaciones que hacen un uso intensivo de la base de datos y las tablas propias como posibles puntos de control. Integración con SQLite No sustituye ni al análisis de dichas consultas ni a la responsabilidad de probar las modificaciones realizadas fuera de la interfaz estándar de WordPress antes de su implementación.

Cuándo es técnicamente viable utilizar SQLite

Una decisión acertada no se basa en una cifra global de visitantes. Lo determinante es la Concurso de redacción: SQLite permite que haya varios lectores en paralelo, pero solo puede realizarse una operación de escritura a la vez por cada archivo de base de datos. Si se producen cambios simultáneos, las operaciones de escritura adicionales deben esperar. La documentación de SQLite recomienda utilizar una base de datos cliente-servidor cuando haya muchos clientes independientes, varios ordenadores o numerosas operaciones de escritura simultáneas.

Algunos ámbitos de aplicación claramente diferenciados son el desarrollo local, la formación, las demostraciones y los entornos de prueba de corta duración. En estos casos, no es necesario configurar un servicio independiente de MySQL o MariaDB, al tiempo que permite comprobar de forma controlada el conjunto de plugins y temas. También puede ser adecuado un sitio web pequeño en un único servidor, siempre que se utilice principalmente para la lectura y los cambios editoriales sean poco frecuentes y no se concentren en un mismo periodo de tiempo.

Sin embargo, una página web corporativa sencilla, un blog personal o una página de campaña no son necesariamente adecuados. Los formularios de contacto, las áreas de miembros, las integraciones de boletines informativos o los puntos finales programados individualmente pueden generar operaciones de escritura adicionales. Por lo tanto, no te limites a comprobar las visitas a las páginas, sino también las actualizaciones de opciones, los envíos de formularios, las tareas programadas y los cambios de datos provocados por plugins e interfaces externas.

En el caso de tiendas online con pedidos, sistemas de reservas y venta de entradas, comunidades activas o aplicaciones con numerosas operaciones de escritura AJAX y REST, esta limitación suele ser más relevante. En estos casos, varios usuarios pueden guardar pedidos, modificar la disponibilidad o crear entradas casi al mismo tiempo. Además, el uso de varios servidores web detrás de un equilibrador de carga tampoco se ajusta al enfoque de archivo local que SQLite requiere para este caso de uso.

El almacenamiento en caché cumple una función distinta a la de SQLite. El almacenamiento en caché de páginas u objetos puede reducir los accesos de lectura recurrentes y, por lo tanto, las consultas a la base de datos; sin embargo, no convierte una aplicación con un uso intensivo de escritura en una instalación de SQLite con pocos conflictos. Por el contrario, SQLite no sustituye a ningún concepto de caché. Por lo tanto, en el caso de los sitios web ya existentes, mantener MySQL o MariaDB junto con un sistema de almacenamiento en caché adecuado puede ser la opción menos arriesgada, sin necesidad de cambiar de plataforma de base de datos.

Evaluar sistemáticamente escenarios con SQLite

Lo que determina si SQLite es adecuado para WordPress no es el número de visitantes, sino la combinación de operaciones de escritura, la configuración del servidor y las extensiones. SQLite puede gestionar accesos de lectura en paralelo, pero no puede ejecutar operaciones de escritura en el mismo archivo de base de datos de forma paralela de manera ilimitada. Por eso, un sitio web individual con muchas visitas no es automáticamente inadecuado, mientras que los pedidos o reservas que se realizan simultáneamente pueden suponer un problema.

La tabla es una preselección, no una aprobación definitiva. Especialmente en el caso de la web de una pequeña empresa, un formulario de CRM, un área de miembros o un servicio de automatización externo pueden convertir una página en la que rara vez se publican entradas en un caso con gran volumen de trabajo de redacción. Por el contrario, un blog con muchos lectores sigue siendo un candidato plausible si los comentarios, los formularios y los cambios administrativos son manejables. El propio plugin señala que la idoneidad depende del tráfico y de la carga de escritura.

En la documentación del proyecto de la rama de desarrollo, «Multisite» se describe como un escenario configurable; además, el repositorio incluye pruebas específicas al respecto. Sin embargo, esto no implica una autorización general para su uso en producción en redes de gran tamaño con numerosos editores, sitios o integraciones. Por lo tanto, trata una red como un caso de compatibilidad independiente y comprueba los procesos de gestión, actualización y contenido que se utilizan realmente.

El paso práctico obligatorio consiste en realizar una prueba de la pila concreta en un entorno aislado. Esto incluye el tema activo, todos los plugins en producción, los plugins MU personalizados, los importadores, los formularios, los puntos finales REST, así como las herramientas de copia de seguridad y supervisión. No solo es decisivo que las páginas se carguen: cada extensión con sus propias consultas SQL o cambios frecuentes debe pasar de forma fiable por la capa SQLite.

Instalación y configuración segura de rutas

Esta configuración es adecuada para una nueva instalación de prueba o para una instalación de SQLite planificada cuidadosamente, pero no como solución rápida para un entorno de producción ya existente. Antes de activarla, PHP debe tener la extensión pdo_sqlite proporcionar compatibilidad con PDO; además, el complemento requiere SQLite a partir de la versión 3.37.0. PHP necesita permisos de escritura para el directorio de la base de datos seleccionado. El cuadro de diálogo de configuración comprueba estas condiciones y detecta, además, los «drop-ins» de bases de datos existentes que puedan entrar en conflicto.

La versión mínima de SQLite indicada es un requisito técnico del complemento, pero no supone una garantía general para todos los casos de uso en producción. Desde la versión 3.0 del complemento, Registro por adelantado (Write-Ahead Logging) activada de forma predeterminada. Por lo tanto, los administradores deberían comprobar qué biblioteca SQLite carga realmente el entorno de ejecución de PHP que utilizan e incluir las actualizaciones de los complementos, de PHP y de SQLite en sus comprobaciones de mantenimiento y compatibilidad.

Prueba especialmente wp-content/db.php. Este archivo es el complemento central de WordPress para la capa de base de datos; no es posible utilizar dos soluciones a la vez. Si ya existe allí un complemento, por ejemplo, para otra conexión a la base de datos o una solución de almacenamiento en caché, antes de la instalación hay que aclarar qué componente proporciona y si es posible desinstalarlo correctamente.

La versión estable 3.1.0 utiliza, de forma predeterminada, subdirectorios con nombres aleatorios en wp-content/database/. La ubicación detectada se muestra en db-path.php registrado y a través de DB_PATH proporcionadas. Por lo tanto, las herramientas de copia de seguridad y migración no deben dar por sentado ningún nombre de archivo histórico ni ninguna ruta predeterminada. Las constantes anteriores DB_DIR y DB_FILE están marcadas como obsoletas en la sección 3.1; DB_PATH tiene prioridad.

Para una nueva instalación planificada, el proyecto recomienda una ruta absoluta fuera del directorio web de acceso público. El directorio de destino debe ser escribible para el proceso PHP. La siguiente configuración debe incluirse en wp-config.php y es un ejemplo de configuración, no unas instrucciones para modificar posteriormente un sitio web ya en funcionamiento.

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

Advertencia: Un nuevo DB_PATH No desplaza ningún archivo de base de datos existente. Selecciona otra ubicación de almacenamiento. Por lo tanto, si se modifica el valor sin la preparación adecuada, WordPress podría utilizar una base de datos diferente o vacía. Planifica conjuntamente la ruta, los permisos de acceso, la copia de seguridad y una prueba de restauración antes de la puesta en producción.

La estructura aleatoria de directorios de la versión 3.1 solo reduce la previsibilidad de la ruta predeterminada. No sustituye ni a los permisos del sistema de archivos ni a una ubicación de almacenamiento protegida de forma fiable contra la divulgación pública. La opción más segura es la ruta recomendada fuera de la raíz web; si se elige otra ubicación, también debe impedirse de forma igualmente fiable el acceso del servidor web a la misma.

No se produce ningún cambio de base de datos mediante la activación

En el caso de un sitio web de WordPress ya existente que utilice MySQL o MariaDB, la activación de la integración de la base de datos SQLite no supone una migración. El plugin crea una base de datos SQLite independiente, inicialmente vacía. Las entradas, los usuarios, las opciones, los archivos multimedia y los datos de los plugins de la base de datos anterior no se transfieren automáticamente. Si la integración se desactiva posteriormente, WordPress volverá a conectarse a la base de datos anterior; los cambios realizados en SQLite no se transferirán de vuelta.

Esta separación resulta útil para las pruebas, pero es esencial para las migraciones en entorno de producción. Quien realmente quiera trasladar contenidos a otra plataforma de base de datos necesita un plan de migración propio y claro que incluya la transferencia de datos, la comprobación de los juegos de caracteres y las opciones, así como un plan de contingencia. El mero cambio del «drop-in» no puede sustituir este proceso.

La denominación bases de datos independientes Hay que entenderlo al pie de la letra: durante el funcionamiento de SQLite, ambas bases de datos pueden contener contenidos diferentes. Una entrada de prueba en SQLite no aparece de repente en MySQL o MariaDB tras desactivarla. Del mismo modo, una nueva entrada de MySQL permanece invisible mientras WordPress utilice el archivo SQLite como fuente de datos activa.

El repositorio wp-sqlite-db Se define a sí mismo como un proyecto independiente con un único complemento de SQLite y hace referencia a la integración original de SQLite. Por lo tanto, no debe equipararse con el repositorio actual de WordPress. Los archivos, los valores de configuración y las instrucciones de este proyecto no deben transferirse a la integración actual de la base de datos SQLite; lo que prevalece en cada caso es la documentación del proyecto concreto que se utilice.

En el caso de los sitios web ya existentes, a menudo la opción menos arriesgada es mantener MySQL o MariaDB y analizar los cuellos de botella por separado. El almacenamiento en caché de páginas u objetos puede reducir las consultas a la base de datos, pero no sustituye a la migración de datos ni resuelve los problemas de compatibilidad de la integración con SQLite. Para clasificar las consultas típicas de WordPress y los enfoques de almacenamiento en caché, resulta útil esta visión general sobre Rendimiento de WordPress y optimización del almacenamiento en caché.

Proteger la base de datos SQLite y realizar copias de seguridad de forma coherente

En SQLite, la base de datos de WordPress se almacena en un archivo en el servidor. Puede contener, entre otras cosas, contenidos, cuentas de usuario, opciones y datos de configuración, por lo que debe protegerse como si se tratara de un servidor de bases de datos. Un subdirectorio predeterminado con un nombre aleatorio, que utiliza la versión 3.1, solo dificulta adivinar la ruta de acceso; no sustituye a unos permisos de archivo correctamente configurados ni a las restricciones de acceso del servidor web.

El proyecto recomienda que:, DB_PATH Establecerlo como una ruta absoluta fuera de la raíz web. PHP necesita derechos de escritura en esa ubicación, mientras que el servidor web no debe servir directamente el archivo de la base de datos. Esta separación reduce el riesgo de que una configuración errónea dentro del directorio de acceso público haga que el archivo sea accesible. La implementación, la gestión de permisos y las copias de seguridad deben tener en cuenta expresamente la ubicación elegida.

En lo que respecta a las copias de seguridad, desde la versión 3.1 es fundamental no introducir de forma fija ningún nombre de archivo histórico ni ninguna ruta predeterminada. El complemento puede obtener la ruta real a través de DB_PATH para que esté disponible en tiempo de ejecución; por lo tanto, las herramientas de copia de seguridad, migración y restauración deben determinarlo tras la carga de WordPress. Antes de ponerlo en producción, deberías realizar la restauración en un entorno independiente y documentar la ruta necesaria, la configuración y los pasos a seguir.

Desde la versión 3.0 del plugin, la integración utiliza de forma predeterminada el modo WAL. En este caso, además de la base de datos principal, se pueden utilizar archivos complementarios con las extensiones -wal y -shm pueden producirse. Por lo tanto, comprueba expresamente si la herramienta de copia de seguridad utilizada es compatible con el modo WAL de la base de datos SQLite en funcionamiento y tiene en cuenta estos componentes. Sin la autorización de dicha herramienta, no es posible obtener una copia de seguridad coherente simplemente copiando el archivo principal.

La versión mínima de SQLite indicada por el complemento, la 3.37.0, establece el límite técnico mínimo para la integración. Para el funcionamiento, debes comprobar además qué versión de SQLite utiliza realmente PHP e incluir las correcciones de seguridad y de errores de los paquetes de PHP y SQLite utilizados en el proceso de actualización habitual. Sin embargo, sin una fuente adecuada en el repositorio existente, no es posible deducir una recomendación fiable para versiones superiores de SQLite o para determinados backports.

Las herramientas de exportación y copia de seguridad no deben utilizarse únicamente porque sean habituales en las instalaciones de MySQL o MariaDB. Comprueba, para cada herramienta concreta, si es compatible con la base de datos SQLite en la versión actual DB_PATH y es compatible con el modo de registro configurado. A continuación, realiza una restauración en el entorno de alojamiento previsto y comprueba si la ruta de la base de datos, los componentes necesarios de la misma y la configuración de WordPress se han fusionado por completo.

Detectar conflictos y analizarlos de forma específica

La migración debe realizarse primero en un entorno de prueba o de staging, no en la primera implementación en producción. Antes de la instalación, registra los archivos existentes en wp-content/db.php así como plugins, plugins MU y extensiones personalizadas que utilizan MySQL directamente. No es posible que una segunda base de datos «drop-in» funcione en paralelo; por ello, el proceso de configuración de la integración comprueba si existen tales conflictos.

A continuación, comprueba los procesos concretos en lugar de limitarte a la página de inicio: registro y administración, creación de contenidos, búsqueda, formularios, tareas programadas, importación y exportación, así como copias de seguridad y restauración. Repite las pruebas tras las actualizaciones de los plugins y de WordPress. La capa de integración procesa la sintaxis de MySQL para SQLite, pero la compatibilidad descrita en el proyecto no sustituye a la comprobación de tus propias consultas o de funciones poco habituales de una extensión.

Entre los errores más comunes en la configuración se encuentra la falta de pdo_sqlite respectivamente pdo o derechos de escritura insuficientes para el directorio de la base de datos. Igualmente problemática es la suposición de que la activación incorpora contenidos de una instalación existente de MySQL o MariaDB: crea una base de datos SQLite independiente, no realiza automáticamente una migración de datos. Del mismo modo, un nuevo DB_PATH no desplaza ningún archivo existente, sino que apunta a otra ubicación.

Si se producen tiempos de espera bajo carga, comprueba primero qué acciones realizan operaciones de escritura simultáneas: por ejemplo, pedidos, procesamiento de formularios, solicitudes REST o tareas en segundo plano. SQLite permite múltiples lectores, pero serializa las operaciones de escritura por cada archivo de base de datos; además, el uso de varios servidores web aumenta los requisitos de la arquitectura de la base de datos. Esto no es comparable con los mecanismos de bloqueo de MySQL-InnoDB. Para el análisis de causas en bases de datos de WordPress convencionales, resulta útil el artículo sobre accesos simultáneos a la base de datos y bloqueos.

Elegir la estrategia de base de datos adecuada

SQLite es una opción aceptable para WordPress si el sitio web se ejecuta en un único sistema, se utiliza principalmente para la lectura y las modificaciones simultáneas son limitadas y conocidas. Esto se adapta mejor al desarrollo local, a las demostraciones o a pequeños sitios web editoriales que a aplicaciones con un gran volumen de transacciones. Un requisito imprescindible sigue siendo la compatibilidad demostrada del tema, los plugins, los importadores y todos los accesos propios a la base de datos que se utilicen realmente.

En el caso de implementaciones distribuidas, varios servidores web u operaciones de escritura concentradas en un mismo momento, se mantienen MySQL o MariaDB la estrategia de base de datos más adecuada. Esto afecta especialmente a tiendas online con pedidos, sistemas de reservas y venta de entradas, funciones comunitarias e interfaces automatizadas con numerosas solicitudes de escritura. Lo determinante no es un número global de visitantes, sino si hay procesos independientes que deben modificar simultáneamente la misma base de datos. Para el acceso directo y simultáneo a la base de datos desde varios hosts a través de una red, SQLite recomienda, por regla general, un sistema cliente-servidor.

Además, en el caso de una página web ya existente, un cambio de plataforma no supone automáticamente un proyecto de optimización del rendimiento. El almacenamiento en caché por objeto o por página puede reducir las consultas a la base de datos y la carga de trabajo de PHP sin necesidad de sustituir MySQL o MariaDB. Así pues, el almacenamiento en caché y SQLite resuelven tareas diferentes: el primero reduce el procesamiento recurrente, mientras que el segundo modifica el modelo de almacenamiento y funcionamiento de la base de datos. Los requisitos oficiales de WordPress siguen indicando MariaDB o MySQL como requisitos habituales para la base de datos.

Antes de dar el visto bueno, una evaluación de «sí/no» debería abarcar, como mínimo, los siguientes puntos:

• Arquitectura: ¿Funciona WordPress de forma permanente en un único servidor sin que varios hosts tengan que abrir el mismo archivo SQLite directamente a través de un sistema de archivos en red?
• Patrones de escritura: ¿Se limitan los pedidos, las reservas, los formularios y las operaciones de escritura REST o AJAX en paralelo, y se comprueban en un entorno independiente?
• Compatibilidad: ¿Funcionan el tema, los plugins, los plugins MU y las consultas SQL personalizadas en la instancia de prueba?
• Drop-ins: ¿El archivo wp-content/db.php no presenta conflictos con soluciones de bases de datos o de almacenamiento en caché?
• Migración: ¿Queda claramente documentado que la activación no transfiere ningún contenido de MySQL ni de MariaDB?
• Tiempo de ejecución: ¿Cumple la biblioteca SQLite cargada por PHP con la versión mínima del complemento? ¿Se incluyen las actualizaciones de PHP, SQLite y del complemento en el proceso de mantenimiento?
• Copia de seguridad: ¿Determina la copia de seguridad la ruta DB_PATH actual?, ¿es compatible con el modo de diario utilizado? y ¿se ha llevado a cabo y documentado una restauración en un entorno independiente?
• Operaciones: ¿Se garantiza la aplicación de las actualizaciones del plugin y de WordPress mediante un proceso de prueba repetible?