Oracle invita a la Fundación MariaDB a su Cumbre de Contribuyentes: el futuro de MySQL en juego

Introducción

La semana pasada, Oracle invitó a la Fundación MariaDB a exponer en su MySQL Contributor Summit 2026, un evento donde los principales contribuyentes del ecosistema MySQL se reúnen para discutir el futuro de la base de datos más usada en producción. La charla, disponible en YouTube (17 minutos), no fue un simple acto protocolar: fue un reconocimiento explícito a que, en un momento donde PostgreSQL avanza a paso firme en adopción —según el DB-Engines Ranking de mayo 2024, MySQL cayó un 2% en los últimos 12 meses mientras PostgreSQL creció un 8%—, la fragmentación interna del ecosistema debilita a todos.

Para equipos de DevOps, SRE e infraestructura, esto no es un tema académico. Las decisiones técnicas de hoy —como la compatibilidad de plugins ABI, la migración entre forks o la elección de motor— impactan directamente en la operatividad, costos y escalabilidad de los sistemas. Si MySQL quiere mantener su ventaja en simplicidad de operaciones y replicación, necesita resolver tensiones que llevan años latentes.

Qué ocurrió

Un espacio inédito: Oracle abre la puerta a MariaDB Foundation

Por primera vez, Oracle invitó oficialmente a la Fundación MariaDB a presentar en un evento de su propiedad, un gesto que trasciende lo protocolar. En su exposición, se destacaron tres puntos clave:

1. La necesidad de interoperabilidad: La charla enfatizó que, en un ecosistema donde conviven MySQL 8.0, MariaDB, Percona Server, VillageSQL y OurSQL, la compatibilidad entre forks no es un lujo, sino un requisito para evitar fragmentación. Como mencionó Heather VanCura (VP de Comunidad en Oracle), citando un dicho popular: «Una marea creciente levanta todos los barcos».

1. Extensibilidad como prioridad: Tomas Ulin (ex VP de MySQL en Oracle, hoy en VillageSQL) subrayó la importancia de estandarizar la ABI (Application Binary Interface) de los plugins. Un ejemplo concreto: hoy, un plugin compilado para MySQL 8.0 puede no funcionar en MariaDB 11.4 sin recompilación. Esto ralentiza la innovación en herramientas como conectores, herramientas de backup o monitoreo.

1. La presión de PostgreSQL: Según datos de Stack Overflow 2024 Developer Survey, PostgreSQL es el motor más queridos por desarrolladores por tercer año consecutivo, mientras MySQL pierde terreno en adopción entre startups y proyectos cloud-native. La fragmentación interna acelera esta tendencia.

El dilema de los forks: ¿Coexistencia o competencia?

MariaDB Foundation ha posicionado a MariaDB como «el sucesor natural de MySQL», argumentando que MySQL 8.0 ya contiene cambios que lo alejan del diseño original de MySQL AB (adquirido por Oracle en 2010). Esta postura generó debates, pero Oracle aceptó el diálogo, algo impensable hace unos años. Como señala Monty Widenius en su post «The concepts of forking»:

> «Forkear un proyecto abierto no es solo copiar código; es mantener compatibilidad, documentar diferencias y construir confianza durante décadas.»

El desafío es claro: ¿Cómo equilibrar innovación independiente con compatibilidad hacia atrás? Un caso reciente lo ilustra: en MariaDB 11.4, se introdujo soporte para el motor de almacenamiento RocksDB como alternativa al InnoDB tradicional, pero esto requiere cambios en aplicaciones que asumen el motor por defecto. ¿Solución? Plugins ABI compatibles que permitan cargar motores sin recompilar.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

La fragmentación del ecosistema MySQL afecta directamente a:

• Migraciones entre motores: Un dump de MySQL 8.0 puede fallar en MariaDB 11.4 si usa sintaxis no soportada (ej.: JSON_TABLE en MySQL vs. JSON_TABLE en MariaDB). Según el blog de la Fundación MariaDB, hay más de 50 diferencias sintácticas documentadas entre ambas versiones.
• Automatización de despliegues: Herramientas como Ansible, Terraform o Kubernetes Operators deben manejar múltiples versiones de MySQL/MariaDB, aumentando la complejidad. Por ejemplo, el operador de MySQL en Kubernetes aún no soporta MariaDB oficialmente.
• Costos ocultos: Mantener réplicas en múltiples forks (ej.: una réplica en MySQL para legacy y otra en MariaDB para nuevas features) duplica el overhead de monitoreo y backups.

Para equipos de Cloud

Los proveedores cloud (AWS, Google Cloud, Azure) ya están reaccionando:

• AWS RDS soporta tanto MySQL como MariaDB, pero no garantiza compatibilidad 100% entre versiones. Por ejemplo, en AWS RDS para MySQL 8.0.36, se menciona que «algunas funciones de MariaDB pueden no estar disponibles».
• Google Cloud SQL tiene un endpoint unificado para MySQL/MariaDB, pero recomienda usar una sola versión para evitar inconsistencias.
• Azure Database for MySQL permite migraciones desde MariaDB, pero requiere pasos manuales para resolver conflictos en triggers o procedimientos almacenados.

Para equipos de Seguridad

La fragmentación genera brechas de seguridad no parcheadas:

• CVE-2024-21097: Una vulnerabilidad en el parser SQL de MySQL 8.0.36 permite inyección de comandos mediante JSON malformado. Esta CVE no afecta a MariaDB 11.4, pero sí a versiones antiguas de MySQL (NVD – NIST).
• Diferencias en autenticación: MySQL 8.0 introdujo el plugin caching_sha2_password, mientras que MariaDB usa ed25519 por defecto. Esto puede romper integraciones con herramientas como Vault o Keycloak si no se configura explícitamente.

Detalles técnicos

Versiones afectadas y vectores de riesgo

Plugin ABI: el talón de Aquiles

La falta de compatibilidad ABI entre plugins es el problema más recurrente en producción. Un ejemplo:

# Compilar un plugin para MySQL 8.0 (requiere glibc 2.31+)
gcc -shared -fPIC -o my_plugin.so my_plugin.c -lmysqlclient

# El mismo plugin en MariaDB 11.4 falla:
./my_plugin.so: symbol lookup error: ./my_plugin.so: undefined symbol: mysql_plugin_interface_version

# En MariaDB 11.4, el archivo de configuración puede incluir:
[mariadb]
plugin_load_add = my_plugin
plugin_abi_compat = 11.4

Sintaxis divergente: el caso de JSON_TABLE

-- MySQL 8.0:
SELECT * FROM JSON_TABLE(jsondata, '$.items[*]' COLUMNS(id INT PATH '$.id')) AS t;

-- MariaDB 11.4:
SELECT * FROM JSON_TABLE(jsondata, '$[*]' COLUMNS(id INT PATH '$.id')) AS t;

Qué deberían hacer los administradores y equipos técnicos

1. Auditar el ecosistema actual

1. Listar todos los motores MySQL/MariaDB en producción:

   mysql -e "SHOW ENGINES;" | grep -E "InnoDB|RocksDB|Aria"
   

1. Verificar diferencias sintácticas con mariadb-diff (herramienta oficial de MariaDB Foundation):

   mariadb-diff --server1=user:pass@mysql:3306 --server2=user:pass@mariadb:3306 --output diff.txt
   

1. Documentar plugins no compatibles y buscar alternativas. Por ejemplo:

– Para mysql_archive, usar archive en MariaDB.

2. Actualizar con estrategia de compatibilidad

• Si usan MySQL 5.7 o inferior: Migrar a MySQL 8.0.36 (últimas versiones con soporte extendido) o a MariaDB 11.4.
• Si usan MariaDB 10.6 o inferior: Actualizar a 11.4 con el comando:

  sudo apt update && sudo apt install -y mariadb-server=1:11.4.2-1ubuntu22.04
  

• Para entornos cloud:

– En Google Cloud SQL: Forzar una sola versión en el clúster (ej.: todas MySQL 8.0.36).

3. Implementar CI/CD para migraciones

# Ejemplo en GitHub Actions para detectar diferencias sintácticas:
- name: Check SQL Syntax Compatibility
  run: |
    docker run --rm -v $(pwd)/sql:/sql mariadb:11.4 mysql -h mysql -e "SOURCE /sql/check.sql"

-- Verificar si el schema usa funciones no soportadas en MariaDB
SELECT COUNT(*) FROM information_schema.routines
WHERE routine_definition LIKE '%JSON_TABLE%';

4. Prepararse para IA y herramientas modernas

MariaDB Foundation anunció su iniciativa MariaDB Skills para integrar IA con bases de datos. Qué hacer:

• Evaluar herramientas como LangChain + MariaDB Connector para evitar lock-in con soluciones propietarias.
• Configurar MCP servers (Model Context Protocol) para que herramientas como Cursor IDE o GitHub Copilot interactúen con MariaDB sin depender de MySQL específico.

5. Monitorear métricas clave

El MySQL Contributor Summit 2026 dejó claro que el futuro del ecosistema MySQL no se define en silos, sino en la mesa de negociación. Oracle, MariaDB Foundation, Percona y otros actores están explorando caminos para convivir sin ahogar la innovación, pero el tiempo apremia: PostgreSQL no espera.

Para equipos técnicos, esto implica:

1. Auditar hoy qué forks usan y qué diferencias sintácticas/ABI tienen.
2. Estandarizar en una sola versión (MySQL 8.0 o MariaDB 11.4) para evitar fragmentación.
3. Automatizar pruebas de compatibilidad en pipelines de CI/CD.
4. Evaluar herramientas modernas (IA, plugins ABI) que reduzcan la deuda técnica futura.

La invitación de Oracle a MariaDB Foundation no fue un gesto vacío: fue un recordatorio de que, en un mundo donde los desarrolladores prefieren PostgreSQL y los costos de fragmentación crecen, el ecosistema MySQL solo sobrevivirá si coopera.

Fuentes

• MariaDB Foundation: Presentación en MySQL Contributor Summit 2026
• MariaDB Blog: Celebrando 15 años de MariaDB
• DB-Engines Ranking: Tendencias de adopción de bases de datos (2024)
• NIST NVD: CVE-2024-21097 en MySQL
• Kubernetes Blog: Operador de MySQL
• MariaDB Skills: Integración con IA