MariaDB 11.8: qué cambia realmente

MariaDB 11.8 llega con mejoras importantes de rendimiento, optimización y compatibilidad, además de nuevas funcionalidades SQL y cambios internos que conviene conocer.
La nueva versión incorpora mejoras importantes de rendimiento, optimización, compatibilidad y nuevas funcionalidades SQL. Y aunque para la mayoría de webs modernas no supondrá ningún problema, sí hay algunos cambios que conviene revisar si trabajas con desarrollos personalizados o aplicaciones antiguas.
Especialmente si tu proyecto depende mucho de consultas SQL avanzadas, collations específicas, procedimientos almacenados o lógica heredada.
La buena noticia es que, en la mayoría de casos, no tendrás que tocar nada.
La menos buena: si tienes código muy antiguo o muy optimizado “a mano”, sí merece la pena hacer algunas comprobaciones.
¿A quién puede afectar esta actualización de MariaDB?
Si utilizas un WordPress actualizado junto con plugins y temas habituales, puedes estar bastante tranquilo/a.
Lo normal es que todo siga funcionando exactamente igual después de la actualización.
Los casos donde sí recomendamos revisar el comportamiento son:
- aplicaciones antiguas o sin mantenimiento
- desarrollos hechos a medida
- integraciones directas con MariaDB
- queries SQL complejas
- configuraciones antiguas de charset o collation
- triggers y procedimientos almacenados
- sistemas con replicación o integraciones externas
Dicho de otra forma: cuanto más personalizado esté el proyecto, más recomendable es validar algunos puntos.
El cambio más importante: utf8mb4 pasa a ser el charset por defecto ⚠️
Uno de los cambios más relevantes de MariaDB 11 es que el charset por defecto deja de ser latin1 y pasa a ser utf8mb4.
Y sí: esto importa más de lo que parece.
¿Por qué puede afectar?
Porque muchas aplicaciones antiguas nunca definieron explícitamente el charset de sus tablas o columnas.
Simplemente, asumían el valor por defecto del servidor.
Con MariaDB 11 eso cambia.
¿Qué puede empezar a comportarse distinto?
Principalmente:
- comparaciones de texto
- búsquedas
- ordenaciones (
ORDER BY) - agrupaciones (
GROUP BY) - igualdad entre cadenas
- tratamiento de caracteres especiales o emojis
En algunos proyectos esto no tendrá ningún impacto.
En otros, especialmente aplicaciones antiguas o multidioma, sí puede provocar diferencias visibles.
Entonces, ¿qué conviene revisar?
Especialmente:
- tablas creadas hace años
- columnas sin charset explícito
- aplicaciones que mezclen diferentes collations
- lógica dependiente del orden exacto de resultados
Si quieres mantener un comportamiento concreto, lo recomendable es definir explícitamente charset y collation en tablas y columnas.
También cambia la collation Unicode por defecto
MariaDB 11.8 utiliza ahora uca1400_ai_ci como collation Unicode por defecto.
Traducido al mundo real: algunas comparaciones y ordenaciones de texto pueden comportarse de forma ligeramente diferente.
¿Dónde suele notarse?
Sobre todo en:
- aplicaciones multidioma
- búsquedas internas
- filtros textuales
- sistemas con ordenaciones complejas
- comparaciones entre caracteres Unicode
Por ejemplo, cadenas que antes se consideraban “iguales” podrían dejar de serlo, o viceversa.
No es algo dramático, pero sí recomendable revisar si tu aplicación depende mucho de búsquedas o comparaciones textuales.
Las queries pueden cambiar de comportamiento (aunque funcionen mejor)
MariaDB 11 incorpora bastantes mejoras en el optimizador SQL.
Y esto, en general, es una buena noticia.
Muchas consultas pasan a ejecutarse de forma más eficiente gracias a nuevos criterios de optimización e índices más inteligentes.
El problema es que, en algunos casos, el plan de ejecución puede cambiar respecto a versiones anteriores.
¿Qué tipo de consultas conviene revisar?
Especialmente:
UPDATEyDELETEcon subconsultas- queries con:
DATE()YEAR()SUBSTR()UCASE()
- tablas particionadas
- columnas virtuales
- consultas muy optimizadas manualmente
MariaDB ahora puede usar índices en situaciones donde antes no podía.
Normalmente esto mejora el rendimiento.
Pero si tu aplicación dependía de un comportamiento muy concreto del optimizador, conviene validarlo.
La recomendación más sensata
Revisar consultas críticas utilizando:
EXPLAIN
sobre todo si el proyecto tiene mucha carga o lógica SQL avanzada.
Los triggers y procedimientos almacenados ahora son más estrictos
Otro punto importante: MariaDB 11 endurece algunas validaciones internas relacionadas con rutinas, triggers y funciones almacenadas.
¿Qué significa esto?
Que ciertos procedimientos antiguos, SQL dinámico o sintaxis poco estándar podrían empezar a dar problemas al recrearse o validarse.
Además, los triggers UPDATE ahora pueden ejecutarse únicamente cuando cambian determinadas columnas.
Esto abre nuevas posibilidades, pero también puede cambiar comportamientos en algunos sistemas heredados.
¿Deberías preocuparte?
Solo si utilizas:
- procedimientos almacenados complejos
- triggers personalizados
- SQL dinámico
- lógica antigua mantenida desde hace años
En aplicaciones modernas o CMS habituales, esto rara vez supone un problema.
Algunas variables antiguas desaparecen o quedan deprecated
Como ocurre en casi cualquier salto importante de versión, MariaDB 11 elimina parte de la compatibilidad heredada.
Algunas variables ya eliminadas
old_alter_tablewsrep_load_data_splitting- variables antiguas de OQGraph
Variables deprecated
tx_isolationspider_casual_read
Qué deberías revisar
Sobre todo:
- scripts de automatización
- configuraciones personalizadas
- herramientas internas
- despliegues antiguos
Muchas veces el problema no está en la aplicación web, sino en scripts olvidados que siguen utilizando sintaxis antigua.
MariaDB 11 también trae mejoras interesantes
No todo son compatibilidades y revisiones 😄
La nueva versión también añade funcionalidades bastante potentes.
Nuevas funciones UUID
Ahora puedes usar:
UUID_v4()
UUID_v7()
directamente desde MariaDB.
Mejoras en JSON
MariaDB sigue mejorando bastante el soporte JSON con funciones como:
JSON_SCHEMA_VALID()JSON_ARRAY_INTERSECT()JSON_OBJECT_FILTER_KEYS()
muy útiles en aplicaciones modernas y APIs.
Funciones vectoriales y búsqueda semántica
Sí: MariaDB también empieza a entrar en el mundo IA.
La nueva versión incorpora:
- tipos vectoriales
- índices vectoriales
- funciones de similitud
orientadas a búsquedas semánticas y aplicaciones modernas relacionadas con embeddings o IA.
Entonces… ¿deberías hacer algo?
Para la mayoría de los proyectos: probablemente no.
Si utilizas aplicaciones modernas, CMS habituales o software actualizado, lo normal es que la migración sea completamente transparente.
Donde sí recomendamos revisar es en proyectos:
- antiguos
- muy personalizados
- con SQL avanzado
- con lógica heredada
- con integraciones directas contra MariaDB
En esos casos, merece la pena validar:
- collations
- queries críticas
- triggers
- procedimientos almacenados
- configuraciones antiguas
Si quieres ir sobre seguro, una buena práctica es probar previamente la aplicación en entornos staging antes de la actualización definitiva, especialmente en proyectos críticos o con mucho desarrollo a medida.