MariaDB en el hosting: averigua quién mantiene la versión que utilizas

El recordatorio de MariaDB Foundation del 31 de octubre trata un cierre anterior: Community 10.6 terminó mantenimiento el 6 de julio de 2026. El comunicado de agosto identifica 10.6.28 como última entrega de la rama. No es un fin de soporte nuevo de esta semana. (MariaDB Foundation, MariaDB Foundation)

Empieza por una observación con procedencia

Pide una lectura autorizada del servidor que atiende a la aplicación y registra cuándo se obtuvo. Después relaciónala con el paquete, distribución o servicio gestionado. Una captura antigua del panel o un requisito en la documentación de la web no demuestra qué motor atiende hoy sus consultas.

La política diferencia Community, Enterprise y Extended, así como distribución de binarios y correcciones en fuente. MariaDB Server se publica bajo GPLv2; una licencia del código no equivale a un contrato de soporte. No intercambies fechas de un nivel con la cobertura contratada para otro. (MariaDB Foundation)

Convierte la respuesta del proveedor en algo comprobable

«Lo mantenemos nosotros» puede ser una respuesta incompleta. Solicita la rama cubierta, el origen del paquete y cómo se documentan actualizaciones aplicadas. Si se menciona una corrección de la distribución o un soporte comercial, pide la referencia correspondiente. Que exista una opción de mantenimiento no demuestra que tu servicio la incluya.

• Identifica quién monitoriza avisos y quién decide introducir una actualización.
• Pregunta cómo se notifica un cambio y qué ocurre si una aplicación no puede asumirlo todavía.
• Separa actualización del motor, conectores y herramientas que también necesitan gestión.
• Anota cobertura desconocida como pendiente, con una persona y fecha de respuesta acordadas.

Compatibilidad de la aplicación y mantenimiento son dos revisiones

WordPress recomienda MariaDB 10.11 o superior. Esa recomendación no identifica tu instalación ni certifica sus temas, plugins, consultas y procesos externos. Utilízala como requisito de aplicación y contrástala con el inventario real. (WordPress.org)

Una aplicación puede seguir respondiendo y, aun así, necesitar una decisión sobre la continuidad del mantenimiento. A la inversa, escoger una rama mantenida no demuestra que todas sus operaciones se comporten igual. Conviene que cada revisión deje una evidencia distinta y que ninguna se dé por superada por el resultado de la otra.

En un ejemplo hipotético, una agencia tiene una tienda y una tarea nocturna de importación. La web parece normal tras un cambio, pero nadie ha revisado el importador. Una aceptación que solo incluya navegar por la portada deja fuera un trabajo que también depende de la base de datos. No se afirma aquí que ese fallo haya ocurrido.

Prepara una decisión, no una actualización improvisada

Elige casos que importen al negocio: consulta habitual, escritura, informe y proceso diferido cuando existan. Trabaja con un entorno aislado y datos autorizados. Fija qué resultados se comparan y quién puede aceptar la diferencia. La duración de una ventana y el destino de la actualización deben salir de esa investigación.

Qué pedir al cerrar la conversación

Reúne versión observada, procedencia del paquete, cobertura y responsables en una ficha breve. Si falta uno, identifica la dependencia antes de escoger una fecha de cambio. No hay en este artículo una receta de producción, una promesa de pocos minutos de parada ni una estimación de ahorro.

Hosting, soporte comercial y trabajo de adaptación tienen costes que deben presupuestarse para el alcance concreto. Si necesitas continuidad después de esa decisión, define la responsabilidad de soporte y optimización junto con las aplicaciones que deben seguir funcionando. La siguiente entrega útil es una respuesta verificable del proveedor, no una versión elegida por ser el número más alto.