Migração de Oracle para PostgreSQL: como planejar sem perder dados

Migrar de Oracle para PostgreSQL costuma começar por uma decisão de custo, mas vira um projeto de engenharia. Licenciamento, suporte e dependência de fornecedor pesam no orçamento; em troca, a migração exige cuidado com código, dados e operação. Este guia resume o que realmente importa para fazer o corte sem perder dados.

Quando a migração faz sentido

A conta não é apenas licença. Vale avaliar a migração quando o custo total do Oracle limita o investimento em produto, quando a versão em uso perdeu suporte ou quando a empresa quer padronizar tecnologia e reduzir dependência de um único fornecedor.

• Contrato de licenciamento ou suporte com custo crescente
• Versão do Oracle sem atualização de segurança
• Necessidade de reduzir o custo total de propriedade
• Padronização em tecnologias abertas e contratação mais fácil
• Projetos novos que podem nascer diretamente no PostgreSQL

O que muda na prática

PL/SQL e objetos de banco

Packages, procedures, funções, triggers e jobs precisam ser reescritos para PL/pgSQL ou para a linguagem da aplicação. Não é tradução linha a linha: tratamento de exceção, cursores, tipos compostos e recursos proprietários do Oracle não têm equivalente direto.

Tipos de dados e particularidades

• NUMBER sem escala: validar precisão e escolher numeric, bigint ou integer
• DATE do Oracle guarda data e hora; no PostgreSQL, date e timestamp são tipos distintos
• VARCHAR2 vira varchar ou text, conforme o uso
• Sequences e identity têm comportamentos diferentes em cache e concorrência
• ROWNUM, CONNECT BY, DUAL e funções como NVL exigem reescrita
• NLS, charset e ordenação podem alterar comparações e relatórios

As cinco fases de uma migração segura

1. Inventário: mapear schemas, volumetria, objetos, integrações, jobs e consultas críticas.
2. Plano por ondas: dividir a migração em etapas com critério de aceite e janela definida.
3. Conversão e testes: ajustar esquema e código, rodar cargas e comparar resultados com o ambiente de origem.
4. Corte controlado: sincronizar a última alteração, executar a janela e validar o sistema com plano de rollback.
5. Estabilização: acompanhar as primeiras semanas, corrigir planos de execução, índices e parâmetros que só aparecem com a carga real.

-- Comparação de volumetria e integridade após carga
SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

Erros que mais atrasam o projeto

• Subestimar procedures, packages e jobs do banco
• Testar apenas com dados de homologação muito menores que produção
• Ignorar diferenças de collation, timezone e formatos de data
• Não medir o tempo de cópia e de sincronização incremental
• Deixar o rollback para o dia do corte
• Não envolver a equipe da aplicação na validação

Checklist antes do corte

• Backup completo e restauração testada no destino
• Contagem e checksum das tabelas críticas conferidos
• Procedures e funções com testes automatizados ou roteiro validado
• Plano de rollback documentado e ensaiado
• Janela comunicada e responsáveis disponíveis
• Monitoramento ativo nas primeiras 48 horas

Conclusão

Oracle e PostgreSQL resolvem problemas parecidos com modelos diferentes. A migração dá certo quando o time trata código, dados e operação como partes do mesmo projeto, com inventário, testes e corte planejado. Se você está avaliando o caminho, um diagnóstico técnico de 30 minutos já mostra os maiores riscos do seu ambiente.