Por que o silêncio no GitHub assustou a comunidade e por que você não precisa migrar seus bancos de dados amanhã.
Nas últimas semanas, um burburinho tomou conta dos fóruns de tecnologia e grupos de DBAs no Brasil: “A Oracle parou de desenvolver o MySQL?”.
O motivo do pânico foi visual e compreensível. Quem acessou o repositório oficial do projeto no GitHub se deparou com uma linha plana no gráfico de atividade — zero commits visíveis desde outubro de 2025. Para quem vive a cultura Open Source, onde a frequência de commits é o batimento cardíaco do projeto, aquele gráfico parecia um eletrocardiograma indicando o óbito.
Mas, antes que o medo se espalhe e CTOs comecem a planejar migrações de emergência, precisamos separar o que é FUD (Fear, Uncertainty, and Doubt — Medo, Incerteza e Dúvida) de como a banda realmente toca dentro da Oracle.
A Percona publicou recentemente uma análise dos fatos e a conclusão é clara: o MySQL está vivo. O problema não é falta de trabalho, é falta de visibilidade.
O GitHub é a vitrine, não a cozinha
O maior erro dessa polêmica foi assumir que a Oracle desenvolve o MySQL no GitHub. Não desenvolve.
Para entender isso, vamos usar uma analogia simples: o desenvolvimento do MySQL funciona como a cozinha de um restaurante chique, e não como um food truck na rua.
Em muitos projetos Open Source comunitários (o food truck), você vê o cozinheiro cortando a cebola, temperando a carne e fritando o hambúrguer em tempo real (os commits diários). Você vê o processo acontecer.
A Oracle opera com a cozinha fechada. Os engenheiros trabalham em repositórios privados, proprietários, longe dos olhos do público. O GitHub, nesse cenário, é apenas a vitrine ou o balcão de entrega. Eles só colocam o prato lá quando está pronto para ser servido.
Silêncio não é inatividade (Code Drops vs. Commits)
O termo técnico para isso é “Code Drop”. Diferente do fluxo contínuo que estamos acostumados a ver em outros projetos, a Oracle acumula meses de trabalho interno e libera tudo de uma vez, sincronizado com o lançamento oficial de uma versão.
Portanto, o gráfico “zerado” no GitHub não significava que ninguém estava codando. Significava apenas que ninguém estava publicando. A prova definitiva veio agora em janeiro de 2026, com o lançamento das versões 9.6.0, 8.4.8 e 8.0.45.
Se o desenvolvimento tivesse sido abandonado em outubro, essas versões — que trazem correções e melhorias — simplesmente não existiriam.
Veredito: Menos pânico, mais contexto
Para a comunidade brasileira de tecnologia, a lição que fica é:
-
O MySQL continua firme: O suporte, a segurança e a evolução do banco de dados continuam ativos.
-
Transparência é outra conversa: Podemos (e devemos) criticar o modelo de desenvolvimento fechado da Oracle, que vai contra o espírito colaborativo do Open Source moderno. Porém, criticar o método é diferente de decretar a morte do projeto.
O gráfico estava parado porque a equipe estava trabalhando offline, não porque tinham desligado os servidores. O MySQL não “foi de arrasta pra cima”; ele apenas trabalha de portas fechadas.
Este artigo foi baseado na análise técnica original publicada no blog da Percona: Separating FUD and Reality: Has MySQL Really Been Abandoned?
COMENTÁRIOS
Muito bom!! Parabéns