MariaDB o MySQL: diferencias

Si alguna vez instalaste un servidor MySQL en Linux, probablemente ya te cruzaste con MariaDB: muchas distribuciones y tutoriales instalan uno en lugar del otro, y los comandos mysql y mysqldump funcionan en los dos. Eso da la impresión de que son lo mismo.

No lo son. MariaDB empezó como fork de MySQL y, en cada versión, ganó funciones que MySQL no tiene (y viceversa). En una app sencilla la diferencia pasa desapercibida; con JSON, replicación o autenticación, aparece.

¿Qué son MySQL y MariaDB?#

MySQL es una base de datos relacional mantenida por Oracle. Su motor de almacenamiento por defecto es InnoDB, con transacciones ACID y bloqueo por fila. Tiene dos líneas de versiones: LTS, que solo recibe correcciones, e Innovation, que trae funciones nuevas. Las fechas de soporte de cada serie están en la política de fin de vida de Oracle. Mira qué es MySQL.

MariaDB es un fork de MySQL mantenido por la MariaDB Foundation y la empresa MariaDB. Lanza versiones LTS con regularidad, cada una con algunos años de soporte de la comunidad, y las versiones que no son LTS tienen soporte corto. La política de mantenimiento de MariaDB muestra qué series tienen soporte.

Fíjate en los números de versión: un número mayor en MariaDB no significa que sea "más nueva" que MySQL, ni que las dos versiones sean equivalentes. Los dos dejaron de seguir la misma numeración hace años, y eso es parte de la divergencia.

¿Por qué se parecen tanto?#

Porque comparten el origen. El protocolo de cliente, la mayor parte de la sintaxis SQL, las utilidades (mysql, mysqldump) y los drivers más comunes funcionan en los dos. Una app que solo usa SELECT, INSERT, índices y transacciones simples normalmente corre en cualquiera de ellos sin cambiar una línea.

La propia documentación de MariaDB dice que las versiones 10.0 y 10.1 solo reemplazaban a MySQL 5.6 de forma limitada y menciona diferencias de implementación. Cuantas más funciones avanzadas usas, menor es la compatibilidad.

¿Qué cambió entre ellos?#

Tres de estos puntos merecen más detalle.

¿Cómo trata cada uno el JSON?#

En MySQL, la columna JSON guarda el documento en un formato binario interno, valida la entrada y permite buscar claves sin releer el documento entero. Una entrada inválida falla con error:

INSERT INTO eventos (datos) VALUES ('[1, 2,');
-- ERROR 3140 (22032): Invalid JSON text: ...

En MariaDB, JSON es solo un alias de LONGTEXT COLLATE utf8mb4_bin, creado por compatibilidad. El valor se guarda como texto, sin cambios, y la validación viene de una restricción CHECK incluida automáticamente. Las funciones JSON_EXTRACT, JSON_VALUE y similares existen en los dos, pero el almacenamiento y la comparación no son idénticos, y la propia documentación de MariaDB advierte que no soporta los objetos JSON empaquetados de MySQL 5.7. Si mueves columnas JSON entre los dos, prueba las consultas y los índices.

¿Qué tiene MariaDB de más?#

Dos cosas que reconoce quien viene de PostgreSQL o de Oracle. La primera es INSERT ... RETURNING, que devuelve las filas escritas en la misma consulta:

INSERT INTO usuarios (nombre) VALUES ('Ana') RETURNING id, nombre;

En MySQL, haces el INSERT y después lees LAST_INSERT_ID() o ejecutas un SELECT. La segunda es la sequence, un generador de números independiente de cualquier tabla:

CREATE SEQUENCE pedidos_seq START WITH 100 INCREMENT BY 10;
SELECT NEXTVAL(pedidos_seq);

CREATE TABLE pedidos (
  id INT PRIMARY KEY DEFAULT NEXTVAL(pedidos_seq),
  total DECIMAL(10,2)
);

MariaDB también tiene un tipo VECTOR(N) para búsqueda por similitud, disponible desde la 11.7. MySQL tiene su propio tipo VECTOR, pero revisa en la documentación de tu edición qué funciones de distancia e índices incluye antes de migrar código de embeddings.

¿Y la replicación?#

Aquí la incompatibilidad es explícita. Según la página de compatibilidad de MariaDB, su GTID no es compatible con el de MySQL (un MySQL 5.6 no funciona como réplica de un MariaDB 10.0) y las variables de sistema son distintas. La misma página dice que el Group Replication de MySQL es incompatible con el Galera Cluster de MariaDB. Si tu plan es un clúster de varios nodos o réplicas de lectura, elige primero el motor y monta la replicación con sus propias herramientas.

¿Se puede cambiar uno por el otro?#

Sí, con cuidado. La migración suele ser más simple cuando la app solo usa SQL estándar. Lo que más se rompe son las columnas JSON, las cuentas de usuario con autenticación sha256_password, performance_schema y sys, la replicación y las vistas creadas por versiones antiguas. Después de arrancar MariaDB sobre un directorio de datos de MySQL, todavía tienes que ejecutar mysql_upgrade (llamado mariadb-upgrade en las versiones recientes) para actualizar las tablas de sistema.

Un plan seguro: exporta con mysqldump, restaura en un servidor de prueba con el otro motor, ejecuta tu suite de pruebas y compara los planes de consulta con EXPLAIN. Mira también cómo hacer una copia de seguridad de una base de datos.

¿Cuál elegir?#

Elige MySQL si tu stack ya lo exige, si la documentación de tu software (CMS, ERP, framework) menciona MySQL primero o si quieres la línea LTS de Oracle.

Elige MariaDB si quieres RETURNING, sequences, Galera o el VECTOR de MariaDB, o si tu distribución Linux ya lo instala por defecto.

El software popular acepta los dos. WordPress, por ejemplo, recomienda versiones LTS con soporte de ambos. En ese caso, elige el que ofrezca tu proveedor y mantente en una versión con soporte.

En cualquier caso, elige una serie LTS con soporte: una versión que ya pasó el fin de soporte no recibe más correcciones de seguridad. Si la duda es más amplia (relacional o NoSQL, PostgreSQL o MySQL), mira qué base de datos elegir y PostgreSQL o MySQL.

Cómo hacerlo en Square Cloud#

Square Cloud ofrece hosting de MongoDB, PostgreSQL, MySQL y Redis a partir del plan Standard; el plan Hobby no incluye hosting de bases de datos. De los dos motores comparados aquí, el disponible es MySQL, siempre en una versión reciente.

Creas la base en el panel y se aprovisiona en segundos en el mismo datacenter que tus aplicaciones (cerca de 1 ms de latencia media). El TLS es obligatorio, con el certificado que descargas en el panel. Puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos tiene también un snapshot automático diario.

Conectas tu aplicación con la URL de conexión que te entrega el panel. Si tu app solo usa SQL común, corre en el MySQL hospedado sin cambios. Si depende de RETURNING o de sequences, ajusta el código antes, porque MySQL no los tiene. Galera también queda fuera: la base es un nodo único. Mira la página de hosting de MySQL.