Ir al contenido

MariaDB no depende de MySQL

·1022 palabras·5 mins
Bases De Datos Opinión
Alejandro Duarte
Autor
Alejandro Duarte
Alejandro Duarte es Ingeniero de Software, escritor, Ingeniero de Relaciones con Desarrolladores en MariaDB y consultor en desarrollo de software. Ha programado computadores desde mediados de los 90s. Comenzando con BASIC, Alejandro transitó a C, C++ y Java durante sus años académicos en la Universidad Nacional de Colombia. Se mudó primero al Reino Unido y luego a Finlandia para profundizar su participación en la industria del código abierto. Alejandro es reconocido en círculos de Java y MariaDB.

Cuando MariaDB fue anunciada por primera vez en 2009 por Michael “Monty” Widenius, se presentó como un “fork de MySQL”. Creo que eso fue una Mala Idea™. Bueno, quizás no fue una mala idea como tal. Después de todo, MariaDB sí es un fork de MySQL. Pero ¿qué es un fork en el sentido del software, y cómo se refleja esto en MariaDB? Un fork es un proyecto de software que toma el código fuente de otro proyecto y continúa su desarrollo de manera independiente. Los forks suelen comenzar manteniendo compatibilidad con su proyecto original, pero pueden evolucionar hasta convertirse en sistemas independientes con sus propias funcionalidades, arquitectura, sistema de seguimiento de errores, lista de correo, filosofía de desarrollo y comunidad. Este es el caso de MariaDB, con el añadido de que sigue siendo altamente compatible con versiones antiguas de MySQL y con su ecosistema actual en general.

Antes de entrar en detalle, aclaro que me gusta MySQL. Fue la primera base de datos que instalé en la universidad, y la usé en proyectos personales y en producción durante mucho tiempo. Entonces, ¿por qué afirmo que posicionar a MariaDB como un fork de MySQL fue una mala idea? En resumen, porque MariaDB no depende de MySQL. Definir a MariaDB únicamente como un fork de MySQL lleva a malentendidos sobre su futuro. Como ejemplo, veamos este viejo comentario en Hacker News que hace referencia a la frase “RIP Open Source MySQL”:

“Perdona mi ignorancia, ¿pero esto no afecta también a los forks de MySQL? Ya que los casos de prueba no estarán disponibles a partir de ahora, por ejemplo, si quisieran reimplementar cierta funcionalidad, ¿no sería mucho más difícil validar que su implementación funciona correctamente?”

Me identifico con el autor de ese comentario. Fuimos llevados, sin querer, a una idea errónea con el eslogan de “fork de MySQL”. Me encuentro con esta falta de claridad más a menudo de lo que me gustaría. Pero la realidad es que el desarrollo de MariaDB ha sido independiente desde hace muchos años. Los desarrolladores de MariaDB no esperan a que MySQL implemente funcionalidades, casos de prueba, corrija errores o innove. Escriben sus propias pruebas, crean sus propias funcionalidades y resuelven problemas a su manera. Cuando Oracle cambia algo en MySQL o restringe el acceso a un componente, eso no tiene un impacto significativo en la hoja de ruta de MariaDB porque los proyectos han divergido tanto que son esencialmente sistemas de bases de datos distintos que comparten un ancestro común, son altamente compatibles (puedes usar conectores y herramientas de MySQL con MariaDB), y están nombrados en honor a los hijos de Monty.

Entonces, ¿por qué hay proyectos como Ubuntu que “dependen” de proyectos upstream (como Debian) y otros como MariaDB que no? En su artículo Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!, David A. Wheeler (director de seguridad de la cadena de suministro de software libre en la Linux Foundation), identifica cuatro posibles resultados para un intento de fork:

  1. La muerte del fork: El resultado más común, ya que mantener vivo un proyecto requiere un esfuerzo considerable.
  2. La reintegración con el original: Ambos proyectos se vuelven a unir.
  3. La muerte del original: Los usuarios y desarrolladores migran al proyecto más joven.
  4. Ramificación exitosa: Ambos tienen éxito con diferentes desarrolladores y usuarios finales.

Durante años, la situación MySQL-MariaDB fue claramente una ramificación exitosa, donde ambos proyectos encontraron nuevos hogares. Uno en Oracle, el otro en el dúo MariaDB Foundation / MariaDB plc. Contrario a lo que muchos pensaban, Oracle invirtió en MySQL y continuó su desarrollo de forma abierta, a pesar de tener su propia base de datos relacional de código cerrado. Durante un tiempo, MariaDB continuó fusionando el código de MySQL commit por commit. Sin embargo, eso cambió en 2014 cuando Oracle dejó de publicar el código fuente de MySQL en Launchpad. Aunque MariaDB aún fusiona cambios de InnoDB, este hecho marcó un punto claro de divergencia en las bases de código.

Hallazgos recientes (y no tan recientes) indican que Oracle ha reducido su ritmo, al menos en términos de innovación, y en el peor de los casos también en mantenimiento. En su artículo Stop using MySQL in 2026, it is not true open source, Otto Kekäläinen (exgerente de desarrollo de software en AWS), muestra que “la cantidad de commits en github.com/mysql/mysql-server ha disminuido significativamente en 2025”. También destaca la fuerte caída en la popularidad de MySQL según DB-Engines, así como los reportes de “rendimiento degradado con versiones recientes de MySQL”. ¿Estamos presenciando una “muerte del original”? No lo sé.

A la luz de todo esto, muchos desarrolladores están empezando a evaluar estrategias de migración hacia otras bases de datos relacionales, siendo MariaDB y TiDB dos de las opciones más atractivas. Según Otto Kekäläinen, “TiDB realmente brilla solo en configuraciones distribuidas grandes, así que para la gran mayoría de aplicaciones pequeñas y medianas que hoy usan MySQL, la solución más práctica probablemente sea cambiarse a MariaDB”. ¿Y el elefante en la habitación? PostgreSQL es una base de datos con montones de forks y extensiones de terceros que se pueden descargar, lo que la hace popular no solo por sus funcionalidades, sino por la cantidad de empresas que promueven su sabor de PostgreSQL en Internet. Para aplicaciones que usan MySQL hoy en día, migrar a PostgreSQL implica bastante trabajo, incluyendo reescritura de código SQL y cambios de conectores. Dos tareas que pueden ser casi cero esfuerzo al cambiar a MariaDB. Mira, por ejemplo, esta transmisión en vivo increíble donde Cantamen (el proveedor líder de “carsharing” en Alemania) migra de MySQL a MariaDB con la ayuda del propio Monty.

Volvamos a mi terca afirmación inicial… MariaDB es un—ahora sabemos—fork independiente de MySQL, y, siendo justos, también se ha posicionado como un “reemplazo de MySQL”, lo cual es muy acertado. Me alegra ver cada vez más el eslogan de “reemplazo” en lugar de “fork”. Personalmente, le sugerí a Kaj Arnö (Presidente Ejecutivo de la MariaDB Foundation) algo incluso más contundente como “MariaDB arregla MySQL”. Quizás es demasiado fuerte. Me alegra que lo hayan suavizado a “MariaDB es el futuro de MySQL”.

¿Te gustó este artículo? Puedo ayudar a tu equipo a implementar soluciones similares. Contáctame para saber más.

Relacionados

Búsqueda por palabras clave vs. búsqueda semántica con IA
·915 palabras·5 mins
Bases De Datos IA
Cómo implementar búsqueda por palabras clave y búsqueda semántica en MariaDB usando Python, LangChain e incrustaciones con IA.
¿Qué puede salir mal al usar transacciones en una base de datos?
·614 palabras·3 mins
Bases De Datos
Los fenómenos de concurrencia son anomalías que todo desarrollador de software debe conocer.
¿Qué es un vector en IA y RAG?
·926 palabras·5 mins
Bases De Datos IA
¿Qué son exactamente las incrustaciones vectoriales en aplicaciones de IA y cómo usarlas en arquitecturas RAG?