MariaDB 11.7: el fork que mantiene su propio camino

Actualizado: 2026-05-03

MariaDB 11.7 (noviembre de 2024) es una release que consolida la dirección independiente del fork respecto a MySQL. Tres áreas reciben atención principal: vector search integrado nativamente —sin extensiones adicionales—, mejoras sustanciales en el soporte de JSON, y optimizaciones del motor de consultas que se traducen en mejoras de rendimiento del 5-15 % en los benchmarks frente a 11.5. Para equipos que eligieron MariaDB hace años y se preguntan si seguir o migrar, esta versión clarifica el argumento.

Puntos clave

• Vector search nativo con índice HNSW: MariaDB 11.7 soporta búsqueda de similitud sin extensiones externas, mientras que MySQL solo lo ofrece a través de HeatWave.
• JSON_OBJECT_AGG y mejoras en JSON paths acercan MariaDB a la paridad funcional con PostgreSQL JSONB para muchos casos de uso.
• La divergencia con MySQL sigue creciendo: Galera multi-master frente a Group Replication, almacenamiento pluggable real frente a InnoDB-centrado, licencia comunitaria frente a Oracle-backed.
• MariaDB no es siempre mejor que PostgreSQL ni que MySQL: cada base de datos tiene sus fortalezas y sus casos de uso óptimos.
• La compatibilidad de aplicación con MySQL sigue siendo alta para operaciones CRUD estándar; la divergencia aparece en características avanzadas.

Vector search: la novedad más relevante

El vector search integrado en MariaDB 11.7 es el cambio que más cambia el mapa de decisión para equipos que ya tienen MariaDB en producción y están evaluando dónde almacenar embeddings para aplicaciones RAG o búsqueda semántica.

La sintaxis es SQL estándar extendida:

-- Crear tabla con columna vectorial
CREATE TABLE documentos (
    id INT PRIMARY KEY AUTO_INCREMENT,
    titulo VARCHAR(255),
    contenido TEXT,
    embedding VECTOR(384)
);

-- Crear índice HNSW para búsqueda eficiente
ALTER TABLE documentos ADD VECTOR INDEX idx_embedding (embedding)
    WITH (M=16, EF_CONSTRUCTION=200);

-- Insertar con embedding
INSERT INTO documentos (titulo, contenido, embedding)
VALUES ('Introducción a eBPF',
        'eBPF permite ejecutar código en el kernel...',
        VEC_FromText('[0.12, 0.34, -0.56, ...]'));

-- Búsqueda de similitud
SELECT id, titulo,
       VEC_DISTANCE_EUCLIDEAN(embedding, VEC_FromText('[...]')) AS distancia
FROM documentos
ORDER BY distancia
LIMIT 10;

El índice HNSW (Hierarchical Navigable Small World) es el mismo algoritmo que usan pgvector y la mayoría de bases de datos vectoriales especializadas. Para equipos que ya operan MariaDB y quieren añadir búsqueda semántica sin añadir una base de datos vectorial separada, este cambio elimina un componente de infraestructura.

Las limitaciones actuales: el vector search de MariaDB 11.7 es funcional pero aún inmaduro comparado con pgvector en términos de opciones de índice, métricas de distancia disponibles y rendimiento a muy alta cardinalidad. Para producción seria, vale la pena evaluar si el rendimiento es suficiente para tu escala específica antes de comprometerse.

Mejoras en JSON

MariaDB ha mejorado el soporte de JSON de forma incremental en cada release reciente. La adición más útil de 11.7 es JSON_OBJECT_AGG, que agrega filas en un objeto JSON:

-- Antes de 11.7: requería concatenación manual o subquery
SELECT usuario_id,
       JSON_OBJECT_AGG(clave, valor) AS preferencias
FROM configuracion_usuario
GROUP BY usuario_id;

-- Resultado: {"tema": "oscuro", "idioma": "es", "notificaciones": "1"}

Junto con mejoras en JSON path expressions y operaciones JSON más rápidas, MariaDB 11.7 reduce la brecha con PostgreSQL JSONB para casos de uso que almacenan datos semi-estructurados en campos JSON. No llega a la paridad completa —PostgreSQL tiene un ecosistema de funciones JSON más rico y sus índices GIN sobre campos JSONB son más flexibles— pero la diferencia práctica se reduce para la mayoría de los usos habituales.

Optimizaciones del motor de consultas

Las mejoras del optimizador en 11.7 se notan especialmente en:

• Joins multi-tabla: mejor estimación de cardinalidad en joins con estadísticas de columnas actualizadas.
• Subconsultas correlacionadas: el optimizador identifica mejor cuándo puede convertir una subconsulta correlacionada en un join, reduciendo escaneos repetitivos.
• Índices de cobertura: mejoras en el uso de covering indexes para evitar accesos a la tabla principal.

Los benchmarks del proyecto MariaDB muestran mejoras del 5-15 % frente a 11.5 en workloads de lectura intensiva. Las mejoras son menores en workloads de escritura pura.

MariaDB frente a MySQL 8: la divergencia crece

La divergencia entre MariaDB y MySQL ha seguido creciendo desde la adquisición de Sun/MySQL por Oracle. Los puntos de diferenciación más relevantes en 2024:

La percepción de comunidad también es diferente: MariaDB tiene una gobernanza más abierta con la MariaDB Foundation; MySQL evoluciona más influenciado por las necesidades de Oracle y de su cloud MySQL HeatWave.

Para equipos que empezaron con MySQL hace años y usan MariaDB como sustituto drop-in, la compatibilidad de SQL y protocolo de red sigue siendo alta para operaciones estándar. La divergencia aparece cuando se usan características específicas de cada fork: replicación avanzada, motores de almacenamiento alternativos o, ahora, vector search.

MariaDB frente a PostgreSQL

La comparación con PostgreSQL es diferente porque son filosofías distintas, no versiones distintas de lo mismo:

• MariaDB: orientada a compatibilidad MySQL, motores de almacenamiento pluggables, Galera para alta disponibilidad multi-master, muy fuerte en workloads de lectura con réplicas.
• PostgreSQL: riqueza funcional (tipos de datos avanzados, extensibilidad, PostGIS, pgvector), ACID robusto, mejor para queries analíticas complejas y JSON semi-estructurado avanzado.

La elección no es “cuál es mejor” sino “para qué workload específico”. Para aplicaciones web con patrones de lectura dominante y equipos familiarizados con MySQL, MariaDB sigue siendo una elección sólida. Para aplicaciones que necesitan JSON avanzado, tipos geoespaciales o vector search de alta cardinalidad, PostgreSQL con sus extensiones tiene más profundidad.

Galera Cluster: el diferencial en alta disponibilidad

Para equipos que necesitan escrituras distribuidas en múltiples nodos con consistencia fuerte, Galera Cluster sigue siendo el argumento más difícil de igualar en el ecosistema MySQL/MariaDB. MySQL Group Replication cubre casos similares, pero Galera tiene más años de rodaje en producción y una comunidad más activa de operadores.

La operación típica de Galera en Kubernetes con tres réplicas activas:

# MariaDB Galera con el operador de Percona
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: mariadb-galera
spec:
  crVersion: 1.14.0
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
  haproxy:
    enabled: true
    size: 2

Para equipos que ya tienen este stack operativo, el upgrade a MariaDB 11.7 mantiene la compatibilidad de Galera y añade las nuevas funcionalidades sin cambios de arquitectura.

Conclusión

MariaDB 11.7 refuerza el argumento de quedarse en MariaDB si ya lo estás usando: vector search nativo sin extensiones adicionales, mejoras JSON sustanciales y un rendimiento incremental que compensa el esfuerzo de upgrade. El argumento para migrar a MySQL o PostgreSQL debe estar basado en necesidades específicas que MariaDB no cubre, no en que MySQL sea “el original” o PostgreSQL sea “el moderno”. Para workloads de web con réplicas de lectura y Galera para HA, MariaDB 11.7 es una plataforma robusta y activamente desarrollada.