O MariaDB 10.6 chegará ao fim da vida útil em 6 de julho de 2026: o que isso significa e como manter a segurança

Principais conclusões

• O MariaDB Community Server 10.6 chegará ao fim de sua vida útil em 6 de julho de 2026. Após essa data, o projeto MariaDB deixará de disponibilizar patches de segurança e correções de bugs para a versão 10.6.
• Operar um banco de dados sem patches em ambiente de produção representa um problema de segurança e conformidade. As normas PCI DSS, HIPAA, SOC 2 e FedRAMP exigem a aplicação oportuna de patches para vulnerabilidades conhecidas.
• A atualização para a versão 11.4 ou 11.8 LTS é a decisão certa a longo prazo, desde que seja possível fazê-la de forma limpa. Quando o prazo é apertado, o Suporte de Ciclo de Vida Ilimitado da TuxCare para o MariaDB mantém a versão 10.6 atualizada com os patches, para que você possa fazer a atualização de acordo com seu próprio cronograma.

Se você estiver executando o MariaDB Community Server 10.6 em ambiente de produção, há uma data que deve marcar no calendário: 6 de julho de 2026. É nessa data que a versão 10.6 chegará ao fim de sua vida útil, e o projeto MariaDB a encerrará. A partir de então, o projeto deixará de lançar novas versões, correções de bugs e patches de segurança para essa versão.

Após 6 de julho, seu banco de dados continuará atendendo às consultas exatamente como fazia no dia anterior. O problema é o que acontece nos bastidores nos meses seguintes: à medida que novas vulnerabilidades são descobertas e nunca corrigidas, os auditores começam a fazer perguntas e o ecossistema em torno da versão 10.6 segue em frente discretamente.

Este artigo aborda o cronograma da versão 10.6, o que o fim do suporte realmente significa para o seu ambiente e as opções viáveis à sua disposição. Se você está procurando uma resposta rápida do tipo “basta atualizar, está tudo bem”, este artigo não é o que você procura. Atualizar um banco de dados em produção raramente é tão simples quanto parece à primeira vista, e o objetivo aqui é ajudá-lo a escolher o caminho mais adequado à sua situação.

Figura 1. Versões LTS do MariaDB e suas datas de fim de vida útil definidas pela comunidade. A versão 10.6 é a próxima a expirar.

Versões e ciclos de vida do MariaDB: um resumo

O MariaDB disponibiliza dois tipos de versões. As versões contínuas são lançadas aproximadamente a cada trimestre e recebem suporte apenas até a próxima versão. As versões com suporte de longo prazo (LTS) são lançadas cerca de uma vez por ano e contam com um período de manutenção mais longo, com correções de bugs e de segurança. Os sistemas de produção devem utilizar uma versão LTS.

O MariaDB 10.6 é uma versão LTS. Ele foi lançado pela primeira vez em 6 de julho de 2021, com um período de manutenção de cinco anos, o que significa que seu fim de vida útil será em 6 de julho de 2026. Desde então, o MariaDB mudou o Community Server para um modelo LTS anual com um período de manutenção de três anos, a partir da versão 11.8 (a versão 11.4 continua sendo uma LTS de cinco anos). Veja a seguir a situação das versões LTS mais recentes em junho de 2026:

Dois pontos se destacam. Primeiro, as versões 10.4 e 10.5 já atingiram o fim do ciclo de vida, e a 10.6 será a próxima, de modo que a maior parte da linha 10.x está fora de suporte — a 10.11 LTS, com suporte até fevereiro de 2028, é a única exceção.  Segundo, as versões LTS com suporte são a 10.11 (até fevereiro de 2028), a 11.4 (até maio de 2029), a 11.8 (até junho de 2028) e a 12.3 (a mais recente LTS, com suporte até 2029). Para equipes que estão migrando da versão 10.6, a 10.11 representa o menor salto de compatibilidade, mas o prazo de suporte mais curto, enquanto as versões 11.4 e 12.3 oferecem o suporte mais longo e são as opções mais discutidas nas conversas sobre atualização.

O que acontece depois que o MariaDB 10.6 atingir o fim do ciclo de vida

O fim do ciclo de vida significa que todos os trabalhos de manutenção são interrompidos. No caso do MariaDB 10.6, isso gera três problemas que se agravam com o tempo:

1. As atualizações de segurança deixam de ser distribuídas

É isso que causa danos reais. A partir de 6 de julho de 2026, as vulnerabilidades que afetam o MariaDB Community Server serão corrigidas apenas nos ramos da comunidade com suporte, enquanto o Community Server 10.6 não receberá mais essas correções. O mecanismo de banco de dados é um alvo de alto valor — ele armazena os dados e, muitas vezes, pode ser acessado a partir de servidores de aplicativos — e uma única falha pode expor tudo o que está por trás dele.

O padrão de exploração em versões em fim de vida é bem conhecido. Quando um projeto lança um patch para uma versão com suporte, a correção é pública; assim, os invasores podem ver exatamente qual código foi alterado e, a partir disso, identificar o bug subjacente. Em seguida, eles procuram essa mesma falha nas versões em fim de vida, que nunca receberão patches. A automação e a análise assistida por IA podem acelerar essa engenharia reversa, de modo que o intervalo entre um patch público e uma exploração funcional pode diminuir rapidamente. Um banco de dados de versões EOL é exatamente o tipo de alvo que esse padrão favorece. 

2. Aumentam os riscos relacionados à conformidade e à auditoria

A maioria das estruturas de segurança exige a aplicação oportuna de correções para problemas conhecidos. O Requisito 6 do PCI DSS espera que as organizações identifiquem, classifiquem por risco e corrijam vulnerabilidades, com a instalação de correções críticas e de alta gravidade no prazo de um mês após o lançamento (6.3.3 na v4.0.1). Os auditores do SOC 2 podem sinalizar componentes sem suporte quando estes representam riscos não resolvidos relacionados ao gerenciamento de vulnerabilidades ou ao gerenciamento de mudanças. Em ambientes regulamentados pela HIPAA, softwares sem suporte podem levantar dúvidas sobre se as salvaguardas técnicas e as práticas de gerenciamento de riscos continuam sendo razoáveis. O FedRAMP e regimes semelhantes exigem a aplicação contínua de patches, acompanhada da documentação correspondente.

O mais frustrante é que o banco de dados pode ser o único componente em fim de vida útil (EOL) em uma pilha de sistemas que, fora isso, está em perfeitas condições, e ainda assim gerar uma constatação de auditoria. As análises de seguros cibernéticos também podem examinar minuciosamente softwares sem suporte, especialmente quando um incidente ou processo de renovação expõe lacunas na aplicação de patches e no gerenciamento de vulnerabilidades.

3. O ecossistema se afasta

Quando uma versão chega ao fim da vida útil (EOL), os softwares relacionados a ela vão, gradualmente, deixando de oferecê-la como compatível. Com o tempo, as distribuições Linux, as imagens de contêineres e os repositórios de terceiros tendem a migrar seus pacotes padrão do MariaDB para versões mais recentes e compatíveis. E, após seis meses, isso se traduz em uma pilha crescente de versões fixadas e soluções alternativas, e a atualização que você vinha adiando, sem perceber, tornou-se mais difícil, e não mais fácil.

Figura 2. As três áreas de risco que se acumulam depois que um banco de dados chega ao fim de sua vida útil.

Quais são suas opções após o fim do suporte (EOL) do MariaDB 10.6?

O caminho ideal para você depende da importância do banco de dados, do nível de sobrecarga operacional que você está disposto a assumir e do seu cronograma realista de atualização. Há quatro opções que vale a pena considerar.

Figura 3. Quatro caminhos após o fim do ciclo de vida do MariaDB 10.6, com as principais vantagens e desvantagens de cada um.

Opção 1: Atualizar para uma versão LTS compatível (10.11, 11.4, 11.8 ou 12.3)

Essa é a resposta clássica e a decisão correta quando é possível executá-la sem problemas. A migração para uma versão LTS com suporte restaura os patches de segurança oficiais e, dependendo da versão de destino, pode trazer melhorias em áreas como o otimizador, o tratamento de JSON, a replicação e as ferramentas operacionais. O MariaDB geralmente mantém a compatibilidade do protocolo cliente-servidor, mas o comportamento das aplicações, a semântica do SQL, a replicação, o formato do binlog, as versões dos conectores e as configurações ainda precisam ser testados antes de uma atualização significativa.

O problema é que uma mudança significativa de versão em um banco de dados de produção exige a revisão do esquema e da configuração, a validação das topologias de replicação, o teste do comportamento das aplicações com a nova versão e o planejamento de um período de inatividade ou de transição. O MariaDB 11.0 introduziu um novo modelo de custo do otimizador — e algumas consultas podem ficar mais lentas —, por isso vale a pena executar sua carga de trabalho real em uma cópia de teste para detectar quaisquer alterações no plano de execução antes que elas cheguem à produção. Uma abordagem comum de menor risco é validar a versão de destino em uma réplica ou cópia de teste restaurada sob tráfego real e, em seguida, planejar a transição e o caminho de reversão antes de promovê-la. A estratégia exata de replicação e promoção depende da sua topologia e de quantas versões principais o salto abrange; portanto, confirme primeiro o caminho de atualização suportado. 

Opção 2: Migrar para o MariaDB Enterprise Server

A MariaDB plc comercializa uma versão comercial do Enterprise Server 10.6, cujo suporte é oferecido até 23 de agosto de 2029, cerca de três anos além do prazo de suporte da comunidade. Como permanece na série 10.6, a mudança se assemelha mais a uma troca de distribuição do que a uma atualização para uma versão principal, e acrescenta recursos empresariais e suporte do fornecedor.

As desvantagens são uma assinatura paga cara, um certo grau de dependência do fornecedor e a mudança da distribuição da comunidade para uma distribuição binária diferente. Para equipes que precisam especificamente do MariaDB Enterprise Server 10.6, com suporte do fornecedor e conformidade com o STIG, essa pode ser uma opção razoável. Para equipes cujo principal objetivo é manter atualizada sua implantação de código aberto existente, essa mudança pode ser maior do que o problema exige.

Opção 3: Manutenção própria ou bifurcação

Em princípio, você pode usar o código-fonte aberto da versão 10.6, acompanhar as CVEs por conta própria e fazer o backport das correções para sua própria compilação. Na prática, isso é difícil de manter. O backport de segurança de bancos de dados exige engenheiros capazes de ler e corrigir corretamente uma grande base de código em C e C++, validar as correções e fazer isso de acordo com o cronograma determinado pelas novas vulnerabilidades, e não com o que você preferiria. A maioria das equipes não consegue contar com pessoal para isso de forma confiável, e um esforço com recursos insuficientes é pior do que nenhum plano, pois cria uma falsa sensação de cobertura.

Opção 4: Segurança ampliada com suporte ao ciclo de vida ilimitado

Esse é o meio-termo pragmático que as equipes tendem a subestimar. O Suporte de Ciclo de Vida Ilimitado da TuxCare para MariaDB mantém sua implantação atual da versão 10.6 protegida contra novas vulnerabilidades após a data de fim de vida útil definida pela comunidade. A TuxCare monitora os CVEs no MariaDB, adapta as correções para a sua versão de código aberto e as fornece como substituições diretas de pacotes por meio do gerenciador de pacotes que você já utiliza. Não há necessidade de reescrever aplicativos, e o objetivo é preservar os fluxos de trabalho existentes de replicação e backup com o mínimo de interrupção operacional.

O objetivo dessa opção é dissociar a urgência de segurança da capacidade de engenharia. Os patches continuam sendo lançados, o aplicativo continua em funcionamento e sua equipe realiza as atualizações de acordo com um cronograma determinado pela realidade da engenharia, em vez de uma data fixa no calendário. Essa opção é adequada quando, realisticamente, sua atualização não será concluída antes de 6 de julho de 2026, quando você tem obrigações de conformidade que exigem a aplicação contínua e documentada de patches, ou quando a implantação está estável e simplesmente não justifica uma grande atualização apressada neste momento.

Por que a atualização nem sempre é a solução imediata

A atualização é a resposta ideal no quadro branco. Na prática, porém, a situação é mais complicada, por alguns motivos que são fáceis de subestimar.

As dependências e integrações costumam ser os verdadeiros obstáculos. O próprio mecanismo do MariaDB raramente retarda as atualizações. O que as retarda é o código da aplicação, os procedimentos armazenados, a configuração de replicação e as ferramentas relacionadas, que assumem o comportamento da sua versão atual. Resolver esses problemas leva tempo, o que uma data fixa de fim de vida útil (EOL) não leva em consideração.

Atualizações apressadas custam muito caro. Elas trazem bugs, deixam de lado casos extremos e economizam nos testes. O custo aparece no trimestre seguinte na forma de incidentes e sobrecarga de plantões, e muitas vezes excede o custo de uma atualização mais lenta e planejada, mesmo levando em conta o suporte estendido.

Alguns sistemas não justificam o esforço neste momento. Um banco de dados que sustenta um aplicativo com substituição prevista, ou que executa uma carga de trabalho fixa sem planos de novos recursos, pode não justificar uma grande atualização este ano. Para esses sistemas, aplicar patches na versão atual até a mudança planejada é uma decisão de engenharia justificável, e não um atalho.

Proteja o MariaDB 10.6 sem precisar atualizar, com a TuxCare

O MariaDB 10.6 tem uma data limite definida: 6 de julho de 2026. Após essa data, o projeto deixará de disponibilizar correções, e todas as novas vulnerabilidades passarão a se acumular em todos os servidores que ainda estiverem rodando a versão 10.6. A atualização para uma versão LTS com suporte — 10.11, 11.4, 11.8 ou 12.3 — é a solução certa quando for possível fazê-la de forma limpa e dentro de um prazo razoável. Quando isso não for possível — seja porque as dependências ainda não estão prontas, o prazo é muito curto ou a implantação não justifica a interrupção —, o suporte estendido mantém você protegido sem forçar uma migração inadequada.

Suporte de ciclo de vida ilimitado da TuxCare para MariaDB preenche essa lacuna com patches de segurança contínuos e respaldados por SLA para versões do MariaDB em fim de vida útil (EOL), fornecidos por meio do seu gerenciador de pacotes existente, sem alterações no código. Se você quiser saber como isso se adapta ao seu ambiente, fale com um especialista da TuxCare. O objetivo é dar a você o controle sobre o cronograma de atualizações, não substituí-lo.

Resumo

Nome do artigo

Fim do ciclo de vida do MariaDB 10.6

Descrição

O MariaDB 10.6 chegará ao fim do ciclo de vida em 6 de julho de 2026. Conheça os riscos de mantê-lo em operação sem patches e quatro maneiras de mantê-lo seguro: TuxCare ELS.

Autor

Artem Karasev

Nome da editora

TuxCare

Logotipo da editora