MariaDB vs. MySQL: ¿importa para tu sitio?

Alrededor del 60 % de los sitios WordPress del gráfico de versiones de bases de datos de WordPress.org usan MariaDB, y alrededor del 40 %, MySQL. WordPress acepta cualquiera de los dos: MariaDB 10.11 o posterior, o MySQL 8.0 o posterior. Probablemente no notarás qué motor hay bajo tu sitio hasta que lo muevas a un proveedor que use el otro.

Una migración así puede atascarse en una sola línea de error. Alguien que exportaba de MySQL 8.0 a MariaDB obtenía Unknown collation utf8mb4_0900_ai_ci en cada intento, y su pregunta en Stack Exchange tiene 74.574 visitas. En nuestro servidor de pruebas (no es un servidor de DreamHost), la migración inversa falló del mismo modo. Una tabla creada con el cotejamiento predeterminado de MariaDB 11.8 detuvo una importación en MySQL 8.4 con Unknown collation: 'utf8mb4_uca1400_ai_ci', mientras que una base de datos de WordPress se movió sin problemas en ambos sentidos.

Qué motor usa cada plan de DreamHost

Todos los planes de DreamHost en los que gestionamos la base de datos por ti usan MySQL. La tabla de versiones del Centro de ayuda de DreamHost indica 8.0 para MySQL compartido y 8.0 u 8.4 para servidores dedicados, según la versión de Ubuntu. La página de MySQL VPS indica MySQL 8.0. La consulta de abajo te muestra cuál usa el tuyo.

El VPS administrado guarda tus bases de datos en los servidores MySQL compartidos de DreamHost, así que sigue la fila del hosting compartido. En el plan Dedicado también puedes instalar la versión de MySQL que quieras, según la descripción general de MySQL del Centro de ayuda de DreamHost.

En el hosting compartido, si tu aplicación necesita MySQL 8.4 antes de que migren tu servidor, la respuesta del Centro de ayuda es añadir un MySQL VPS y mover allí tus bases de datos. Antes de añadirlo, comprueba si tu base de datos está ralentizando tu sitio y, si también estás comparando precios de bases de datos en la nube, consulta los precios de RDS for MySQL frente a un servidor MySQL privado.

Cómo comprobar el tuyo

1. Abre phpMyAdmin
   Inicia sesión en phpMyAdmin desde tu panel de DreamHost o desde las herramientas de tu propio servidor.
2. Haz clic en la pestaña SQL
   Se abre un cuadro en el que puedes escribir una consulta al servidor.
3. Ejecuta la consulta de versión

   Pega esto y ejecútalo:

   sqlCopiar

   SELECT VERSION();

   Un servidor MySQL responde solo con un número, como 8.4.11. Un servidor MariaDB incluye su nombre en la respuesta, y el nuestro devolvió 11.8.9-MariaDB-ubu2404.

En un VPS que configuras tú, la versión de Linux decide qué te instala apt install. Ubuntu 24.04 incluye MySQL 8.0 y MariaDB 10.11. Ubuntu 26.04 incluye MySQL 8.4 y MariaDB 11.8. Debian 13 tiene MariaDB 11.8 y ningún paquete de servidor MySQL, y su paquete default-mysql-server instala MariaDB. Nuestra prueba lo confirmó y mostró que default-mysql-server de Ubuntu hace lo contrario: instala MySQL, 8.4 en 26.04 y 8.0 en 24.04. En nuestro LAMP Stack VPS, la misma consulta te indica qué versión de MariaDB tienes. Si aún no has elegido Linux, nuestra guía sobre qué Linux usar en tu VPS compara las cuatro distribuciones que ofrecemos.

Qué cambia entre MySQL 8.4 y MariaDB 11.8

MariaDB la crean los desarrolladores originales de MySQL. Los dos se han ido distanciando, y la lista de diferencias de MariaDB es larga. Estas son las que puede encontrarse quien gestiona un sitio.

Lo más probable es que te topes primero con la fila del cotejamiento. MySQL 8 etiqueta las nuevas columnas de texto con utf8mb4_0900_ai_ci, y MariaDB 11.4 y posteriores usan utf8mb4_uca1400_ai_ci, según la matriz de compatibilidad de MariaDB. Una exportación incluye esos nombres en cada línea CREATE TABLE. La lista de diferencias de MariaDB indica que 11.8 conoce 550 cotejamientos, incluidos 44 alias que añadió en 11.4.5 para facilitar la replicación desde MySQL. En nuestra prueba, MariaDB 11.8 aceptó sin quejas una tabla de MySQL 8.4 etiquetada con utf8mb4_0900_ai_ci. Al revés falló, porque MySQL 8.4 no conoce utf8mb4_uca1400_ai_ci, y la importación se detuvo con ERROR 1273. WordPress no se topa con ninguno de los dos problemas: creó todas las tablas con utf8mb4_unicode_520_ci en ambos motores.

La configuración de serie importa si comparas los dos por tu cuenta. MySQL 8.4 activa el registro binario de fábrica, y MariaDB deja su registro binario desactivado. Performance Schema sigue la misma división: activado en MySQL y desactivado en MariaDB 11.8. Una prueba comparativa que no toque ninguno compara dos archivos de configuración tanto como dos motores, así que hicimos la nuestra de las dos formas.

Memoria, velocidad y disco en nuestro servidor de pruebas

Sin ninguna conexión, MySQL se quedó en 427 MiB de memoria y MariaDB en 137 MiB. Ejecutamos las imágenes oficiales de MySQL 8.4.11 y MariaDB 11.8.9 de una en una en una VM de pruebas con 2 vCPU y 4 GB de memoria, el mismo tamaño que nuestro plan Stack 4.

En velocidad, los dos quedaron más o menos igual una vez igualada la configuración. Cada motor ejecutó la prueba una vez por configuración, demasiado pocas veces para afirmar que uno es más rápido.

Notarías la diferencia de memoria en un servidor pequeño, donde la base de datos comparte la RAM con PHP y tu servidor web. De los 3904 MB de nuestra VM de pruebas, quedaban disponibles 3465 MB con MariaDB en reposo y 3136 MB con MySQL. Justo después de la prueba de rendimiento, desactivar los dos extras de serie de MySQL redujo su diferencia respecto a MariaDB de 356 MiB a 101 MiB. Para dimensionar un servidor de bases de datos, consulta cuánta RAM necesita MySQL.

¿Le importa a tu aplicación?

Instalamos WordPress 7.1.3 en cada motor, generamos 200 entradas y 500 comentarios, y cargamos la página de inicio sin errores en ninguno de los dos. Las aplicaciones de la tabla de abajo funcionan igual: consulta la página de requisitos de tu aplicación antes de pensar en el motor y normalmente verás los dos con una versión mínima. Los datos proceden de la página de cada aplicación, consultada el 16 de octubre de 2026.

Ghost es la única aplicación de esta lista a la que le importa. Su página de bases de datos compatibles indica que MySQL 8 es la única base de datos compatible en producción y recomienda encarecidamente dejar MariaDB si lo usas.

Nextcloud 35 también merece un segundo vistazo. Sus requisitos incluyen MySQL 8.4 y 9.7, pero no 8.0. En un servidor que gestiones tú, usa MySQL 8.4 o una de las versiones de MariaDB que indica.

Cómo mover una base de datos de uno a otro

Para mover una base de datos entre MySQL y MariaDB, en cualquier sentido, la exportas a un archivo SQL e importas ese archivo. La guía de migración de MariaDB responde a Can I perform an in-place upgrade? con un rotundo No para quien venga de MySQL 8.0 u 8.4. No puedes copiar los archivos sin más.

1. Comprueba la versión en ambos servidores
   Ejecuta SELECT VERSION(); en el servidor antiguo y en el nuevo. Saber de qué motor partes te indica qué nombres de cotejamiento buscar en el paso 3.
2. Exporta con la herramienta del servidor antiguo

   En MySQL, usa mysqldump de MySQL. La guía de migración de MariaDB lo pide, ya que el propio mariadb-dump de MariaDB apenas se ha probado con MySQL. En MariaDB, usa mariadb-dump. Indica una sola base de datos y omite --databases, para que el archivo no tenga ninguna línea CREATE DATABASE:

   bashCopiar

   mysqldump --user=USER \
     --password \
     --single-transaction \
     --routines --triggers \
     --hex-blob \
     DBNAME > site.sql

   El artículo sobre errores de importación de DreamHost explica que una línea CREATE DATABASE hace que la importación falle con ERROR 1044. Si vas a migrar a DreamPress, omite --routines y --triggers, porque los servidores MySQL de DreamPress no admiten rutinas almacenadas ni disparadores.

3. Cambia los nombres de intercalación que el nuevo servidor no reconozca
   Una base de datos de WordPress normalmente se salta este paso, ya que en nuestra prueba WordPress usó utf8mb4_unicode_520_ci en ambos motores y se movió en los dos sentidos sin errores. Las tablas con el cotejamiento predeterminado del servidor pueden fallar en un sentido. MySQL 8.4 se detuvo en Unknown collation: 'utf8mb4_uca1400_ai_ci' en una exportación de MariaDB 11.8, mientras que MariaDB 11.8 aceptó utf8mb4_0900_ai_ci de MySQL. Las versiones anteriores de MariaDB lo rechazan, como en la pregunta de Stack Exchange. Sustituye el nombre desconocido en todo el archivo por utf8mb4_unicode_520_ci, que ambos motores conocen, y vuelve a importar. Esa es la solución que usaron las respuestas más votadas en Stack Exchange, y es el cotejamiento que eligió WordPress en ambos motores en nuestra prueba.
4. Importa en una base de datos vacía
   Primero crea la base de datos y su usuario en tu panel y luego importa el archivo en phpMyAdmin o con el cliente mysql. En nuestra prueba, los volcados de mysqldump y mariadb-dump establecían su propio juego de caracteres. Si pasas un archivo SQL escrito a mano al cliente mysql dentro de la imagen oficial de Docker de MySQL, añade --default-character-set=utf8mb4: sin él, en nuestra prueba ese cliente recurrió a latin1 y estropeó las letras acentuadas.
5. Prueba el sitio antes de cambiar las DNS
   Carga unas cuantas páginas, inicia sesión en el panel de administración, haz una búsqueda y guarda una entrada.

Cuál elegir

Para un sitio PHP, recomendamos el motor que ya usa tu proveedor de hosting, en una versión con soporte.

Si usas MySQL 8.0, tu siguiente paso es MySQL 8.4, y puedes llegar a él sin dejar MySQL. Oracle pasó MySQL 8.0 a su fase de Sustaining Support el 21 de abril de 2026 y recomienda actualizar a 8.4 o 9.7. Según el Centro de ayuda de DreamHost, los servidores dedicados ya están pasando a 8.4, los servidores compartidos lo harán según el calendario de DreamHost y los clientes de MySQL VPS pueden contactar con soporte para solicitarlo.

Cómo lo medimos

Hicimos la prueba el 19 de octubre de 2026 en una máquina virtual con Colima en un Mac con Apple M2: arm64, 2 vCPU, 3904 MB de memoria visible, sin swap, Ubuntu 24.04.4 y Docker 29.5.2. No usamos ningún servidor de DreamHost. Usamos las imágenes oficiales mysql:8.4.11 y mariadb:11.8.9, fijadas por digest, y no cambiamos nada en las pruebas con la configuración de serie. La memoria en reposo es la mediana de 12 lecturas de docker stats tomadas cada 5 segundos tras 2 minutos de estabilización, y 10 minutos después seguía igual. La prueba de rendimiento fue el test oltp_read_write de sysbench 1.0.20 con 4 tablas de 100.000 filas, que caben en el buffer pool predeterminado de 128 MB de cada motor, 4 hilos, 60 segundos de calentamiento y una sola ejecución de 120 segundos por motor y configuración.

Nuestros servidores VPS y dedicados usan procesadores AMD EPYC, así que compara los motores por proporción y no esperes los mismos valores absolutos. No probamos un MySQL VPS, el MySQL compartido ni nuestra imagen LAMP Stack. Cada prueba de rendimiento se ejecutó una sola vez, con datos sintéticos más sencillos que el tráfico de un sitio real. Además, la ejecución de MariaDB registró 683 errores que sysbench reintenta y cuenta aparte (unos 6 por segundo), mientras que la de MySQL no registró ninguno; no investigamos el motivo. La comprobación de WordPress abarcó la instalación, el contenido generado y la carga de páginas, y cada migración usó la herramienta de volcado del motor de origen.

Preguntas frecuentes sobre MySQL y MariaDB