Guia
Por Marcio Maciel · Sócio-fundador · Engenharia de Negócio Digital
Publicado em 17 de julho de 2026
MySQL 8.0 saiu de suporte da Oracle em 30 de abril de 2026. Operações Adobe Commerce / Magento 2.4.5 e 2.4.6 que ainda dependem desse banco acumulam risco composto com o fim de suporte da linha de plataforma. No on-premise, a Adobe recomenda migrar o servidor de banco para MariaDB compatível; no Adobe Commerce on Cloud, a obrigação documentada é manter dependências de plataforma em versões suportadas pela política de ciclo de vida. O custo de atualizar banco e/ou Adobe Commerce / Magento para versões suportadas precisa entrar no TCO. A Magecore atualiza infraestrutura e Adobe Commerce / Magento em Cloud e on-premise.
Na documentação da Oracle, MySQL 8.0 atingiu end of support em 30 de abril de 2026. Depois dessa data, a linha 8.0 deixa de receber o ciclo regular de correções de segurança que a operação espera de um banco em suporte ativo.
A Adobe confirma a mesma data na orientação de compatibilidade de banco para Adobe Commerce. Para as linhas 2.4.5, 2.4.6 e 2.4.7, a Adobe deixa explícito que, após o EOS do MySQL 8.0, não valida nem mantém compatibilidade com versões MySQL lançadas depois da 8.0 nessas releases. Suporte estendido da plataforma Adobe Commerce, quando disponível, não estende suporte a dependências de terceiros como MySQL.
Cloud e on-premise não são o mesmo caso. A matriz de requisitos da Adobe separa Commerce on Cloud de Commerce on-premises: versões de serviço testadas no hosting Cloud podem diferir das suportadas em instalação própria.
Quem permanece em Adobe Commerce / Magento 2.4.5 ou 2.4.6 com MySQL 8.0 no on-premise combina dois riscos: banco fora do suporte Oracle e linha de plataforma que a Adobe não vai alinhar a MySQL mais novo. CVE no banco sem patch, pressão de auditoria (PCI e políticas internas) e custo reativo de incidente passam a competir com o orçamento de evolução.
No Cloud, o risco aparece quando serviços ou a linha de Adobe Commerce / Magento ficam fora do que a política de ciclo de vida ainda cobre. Mesmo com MariaDB no template, plataforma e dependências desatualizadas continuam no P&L como risco operacional, não só como item de infra.
Não existe um único caminho obrigatório. O que muda é a ordem e o escopo, conforme Cloud ou on-premise e conforme o estado real da instalação.
O próximo passo útil é mapear estado real: versão de Adobe Commerce / Magento, Cloud ou on-premise, motor e versão de banco, patches aplicados, restrições de PCI e custo reativo recente. Com isso dá para escolher entre atualizar só o banco, só a plataforma, ou ambos na mesma janela.
Assessment aqui serve para priorizar risco e TCO, não para pressupor migração de arquitetura ou troca de distribuição. O diagnóstico gratuito e o Assessment de Precisão existem para transformar “MySQL 8.0 saiu de suporte” em plano com números no P&L.
Perguntas relacionadas
É um diagnóstico multidimensional assistido por IA que identifica vazamentos de margem e débito técnico em operações Adobe Commerce / Magento, entregue em 1 a 3 semanas.
O entregável inclui mapa de custos invisíveis, priorização de intervenções com impacto em reais e recomendação clara: migrar, otimizar ou manter a plataforma atual.
Em migrações para arquitetura modular com observabilidade, reduções de 25% a 50% no TCO de infraestrutura em 12 meses são metas realistas para operações de médio porte.
O percentual exato depende do ponto de partida: operações com alto custo reativo em legado tendem a resultados na faixa superior; cada caso é quantificado no diagnóstico.
Próximos passos
