MariaDB 13 chega em GA com compatibilidade nativa ao PL/SQL da Oracle
A nova versão estável do MariaDB Community Server adiciona REF CURSOR e RECORD em rotinas armazenadas, RETURNING para UPDATE e mais controle sobre hints de otimizador, mirando quem migra de banco legado.
O MariaDB Community Server 13.0 atingiu General Availability (GA) em setembro, segundo reportagem do InfoQ, e o pacote de novidades mira diretamente quem trabalha com bancos híbridos ou migrações vindas de Oracle↳Oracle22 conteúdosOracle lança Java 26 para aumentar produtividade de desenvolvedoresDev (Back & Front) · mar 2026Oracle oferece o primeiro cluster de computação em nuvem em escala ZettaDevSecOps · jan 2025Oracle abre inscrições para o ONE, programa gratuito de formação em tecnologia e inteligência artificialData · dez 2024Ver tudo em Data →. A versão traz suporte nativo a REF CURSOR e RECORD em rotinas armazenadas, uma cláusula RETURNING mais completa e melhorias no framework de hints de otimizador introduzido na versão 12.
Vale lembrar o contexto: o MariaDB segue modelo de rolling release, entregando recursos novos rapidamente em vez de mirar estabilidade de longo prazo. Quem precisa de LTS deve esperar a próxima versão planejada para esse propósito, a 13.3, que herdará essas mudanças já maduras.
REF CURSOR e RECORD: menos reescrita ao sair da Oracle
A dor mais comum de quem porta aplicações Oracle PL/SQL para MySQL/MariaDB sempre foi a semântica de cursores e tipos estruturados. O MariaDB 13 ataca isso de frente com suporte a REF CURSOR fraco e forte, que podem ser abertos, percorridos (fetch) e fechados como variáveis locais, parâmetros de rotinas de pacote ou tipos de retorno de funções de pacote.
Na prática, uma função Oracle que devolve um cursor de referência para o código chamador processar linha a linha agora tem caminho de portabilidade direta, sem reescrever a lógica como um conjunto de SELECTs isolados. O tipo RECORD, que já existia para variáveis locais, passa a valer também como parâmetro de rotina armazenada ou tipo de retorno de função armazenada, e pode ser combinado com REF CURSOR para trabalhar com dados de linha estruturados, típico de quem manipula registros vindos de PL/SQL.
A ressalva importante: nem REF CURSOR nem RECORD funcionam ainda como parâmetro ou retorno de rotinas globais (fora de pacote). Isso significa que times migrando código Oracle precisam organizar a lógica em pacotes MariaDB para aproveitar o recurso por completo, algo que já era esperado dado que o suporte a pacotes do MariaDB nasceu justamente para espelhar o modelo de packages do PL/SQL.
RETURNING chega ao UPDATE, e isso poupa uma viagem ao banco
Até aqui, a cláusula RETURNING no MariaDB só valia para INSERT e DELETE. Na versão 13 ela passa a funcionar também com UPDATE, e o ganho prático é direto: dá para capturar as linhas modificadas no mesmo comando que faz a alteração, sem precisar de um SELECT posterior.
O detalhe que separa isso de um RETURNING genérico é a combinação com a função OLD_VALUE(). Com ela, é possível recuperar valor antigo e valor novo de uma coluna numa única viagem ao banco, o tipo de operação que normalmente exigia dois round trips (um SELECT antes do UPDATE, outro para conferir o resultado) ou gatilhos auxiliares só para auditoria. Para quem constrói trilhas de auditoria, sincronização de cache ou logs de mudança de estado direto na aplicação, isso reduz latência e simplifica código que hoje depende de triggers.
A limitação por enquanto: RETURNING em UPDATE só vale para statements de tabela única, então joins multi-tabela com atualização em cascata continuam fora do escopo do recurso.
Hints de otimizador ficam mais fáceis de apontar
O MariaDB 12 já havia introduzido um framework de hints para o otimizador de consultas. A versão 13 melhora a ergonomia dele: agora Views, CTEs e tabelas derivadas recebem automaticamente um nome de bloco de consulta, o que permite mirar hints nelas sem precisar declarar QB_NAME() manualmente.
Para consultas complexas, com múltiplos níveis de subqueries e CTEs aninhadas, isso reduz boilerplate. Quando o bloco não pode ser identificado só pelo nome (por estar profundamente aninhado), os chamados QB_NAME locators entram como caminho explícito até o bloco certo. É o tipo de ajuste que interessa a quem já lida com planos de execução manualmente e usa hints como ferramenta de tuning fino em produção, não como curiosidade acadêmica.
Observability: menos SHOW CREATE TABLE, mais metadado consultável
A parte de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → e administração também ganhou peso. A variável init_rpl_role, que antes só existia como opção de linha de comando na inicialização, agora é exposta como variável de sistema, o que permite checar o papel de replicação do servidor diretamente via SHOW VARIABLES ou @@init_rpl_role, sem depender de inspecionar o processo de boot ou arquivos de configuração.
Outra mudança mira quem automatiza inspeção de schema: as tabelas I_S.STATISTICS e I_S.COLUMNS agora trazem uma coluna CREATE_OPTIONS, expondo opções específicas de storage engine para índices e colunas que antes só apareciam no texto solto de SHOW CREATE TABLE. Isso importa para ferramentas de linhagem de dados, scripts de auditoria de schema e pipelines de CI que validam estrutura de tabela: parsear uma coluna estruturada é mais confiável do que fazer regex em cima da saída de SHOW CREATE TABLE.
Por fim, I_S.SYSTEM_VARIABLES ganhou colunas indicando se uma variável de sistema está deprecada, facilitando checagens automatizadas antes de upgrades, um problema recorrente em times que mantêm múltiplas instâncias MariaDB em versões diferentes.
O que ainda falta olhar de perto
A reportagem do InfoQ não detalha número de versão mínima do MariaDB Connector necessário para explorar RETURNING com OLD_VALUE() nem client libraries atualizadas para consumir REF CURSOR em pacotes, então quem for testar migração de PL/SQL vale checar a documentação oficial do MariaDB antes de assumir compatibilidade total com drivers já em uso. Também fica em aberto até que ponto o suporte a REF CURSOR e RECORD em rotinas globais chega em versões futuras, algo que pode facilitar ainda mais a portabilidade de código legado que não usa pacotes.
Para quem hoje mantém uma camada de compatibilidade caseira entre PL/SQL e MySQL/MariaDB, feita na marra com stored procedures reescritas à mão, o MariaDB 13 reduz parte desse atrito, mas não elimina a necessidade de revisar cada rotina migrada caso a caso.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
