Migrar SQL Server ou Oracle para PostgreSQL: vale a pena?

A renovação do contrato de licenças chega, o fornecedor muda a regra de contagem de núcleos e o financeiro pergunta por que o banco de dados custa mais que o próprio servidor. Ao mesmo tempo, a equipe quer subir o sistema para a nuvem e descobre que a edição comercial do banco amarra o tipo de máquina, a forma de licenciar e até o provedor.

É nesse momento que o PostgreSQL entra na conversa. Ele é gratuito, maduro, roda em qualquer nuvem e em servidor próprio, e é usado em sistemas críticos no mundo todo. Se a dúvida é entre ele e o MySQL, veja PostgreSQL ou MySQL. A pergunta deixa de ser "dá para usar PostgreSQL?" e passa a ser "quanto trabalho dá sair do que temos hoje, e o que pode quebrar no caminho?".

A resposta curta: migrar SQL Server ou Oracle para PostgreSQL vale a pena quando o custo e a dependência do banco comercial pesam mais que o esforço de reescrever o que vive dentro dele. Copiar tabelas e dados é a parte fácil. O trabalho de verdade está nas procedures, nos relatórios e nas integrações que conversam direto com o banco. Este texto mostra como avaliar, o que esperar de cada parte e como fazer a virada com caminho de volta.

Por que tantas empresas consideram a troca

Os motivos costumam aparecer juntos, e vale separar cada um para saber qual pesa mais no seu caso:

• Licença. Bancos comerciais costumam ser licenciados por núcleo ou por servidor e acesso, variam por edição e, no caso do Oracle, cobram à parte por opções adicionais. Crescer o servidor, criar uma réplica ou um ambiente de homologação pode significar comprar mais licença.
• Nuvem. Levar o sistema para a nuvem com banco comercial exige escolher entre trazer a própria licença, com regras específicas de cada provedor, ou pagar a licença embutida no serviço gerenciado. Com PostgreSQL, AWS, Azure e Google Cloud oferecem serviço gerenciado em que se paga a infraestrutura, sem licença do banco.
• Dependência de fornecedor. Auditoria de licença, mudança unilateral de política comercial e fim de suporte de versão são riscos que a empresa não controla.
• Equipe. Encontrar quem conheça PostgreSQL é mais fácil do que era há alguns anos, e o ecossistema de ferramentas, extensões e bibliotecas é amplo.
• Modernização. Muitas vezes a troca de banco é parte de um projeto maior de modernização do sistema, e faz sentido aproveitar a mesma janela.

Nenhum desses motivos, sozinho, justifica a migração. Uma empresa com contrato estável, sistema que funciona e nenhum plano de nuvem pode simplesmente não ter ganho suficiente para pagar o esforço.

Licenças, nuvem e independência de fornecedor

A conta que interessa ao gestor não é "licença contra zero". É o custo total do banco comercial nos próximos anos comparado com o esforço único da migração mais o custo de operar o PostgreSQL.

Do lado do banco atual, entram licença, suporte anual, as licenças extras de réplica e homologação e o efeito da licença na escolha de infraestrutura. Do lado do PostgreSQL, entram o projeto de migração, o tempo de teste, o treinamento da equipe e a operação: backup, monitoramento e atualização, que continuam existindo, só que sem licença.

Na nuvem, o serviço gerenciado de PostgreSQL resolve boa parte da operação e permite dimensionar a máquina pelo uso real, não pela licença. Se a migração para a nuvem já está no radar, vale ler também como reduzir custos de nuvem, porque um banco superdimensionado continua caro mesmo sem licença, e o roteiro de migrar servidor local para a nuvem, se o banco hoje roda em máquina própria.

Há um ganho menos visível: independência. Com PostgreSQL, a empresa pode trocar de provedor de nuvem, voltar para servidor próprio ou mudar de fornecedor de suporte sem reescrever o banco de novo.

O que migra fácil e o que dá trabalho

Antes de qualquer decisão, é preciso um inventário do que existe dentro e em volta do banco. A tabela abaixo resume o que costuma ser simples e o que costuma consumir o projeto.

Diferenças de tipo e comportamento que pegam desprevenido

Alguns detalhes passam despercebidos na conversão automática e só aparecem quando um relatório mostra número diferente:

• Maiúsculas e minúsculas. O SQL Server normalmente compara texto sem diferenciar maiúsculas. O PostgreSQL diferencia. Uma busca por "SILVA" que achava "Silva" pode parar de achar. Dá para resolver com ILIKE, com a extensão citext ou com collation que ignora maiúsculas, mas a escolha precisa ser feita antes.
• Texto vazio e nulo. No Oracle, texto vazio é tratado como nulo. No PostgreSQL, são coisas diferentes. Regras que testam "campo vazio" mudam de resultado.
• Datas. O tipo DATE do Oracle guarda hora, minuto e segundo; o DATE do PostgreSQL guarda só o dia. Mapear um no outro sem cuidado corta a hora dos registros, e o equivalente costuma ser TIMESTAMP.
• Numeração automática. IDENTITY no SQL Server e sequences no Oracle têm equivalente no PostgreSQL, mas o valor atual precisa ser ajustado depois da carga para não gerar chave duplicada.
• Funções próprias. TOP e ROWNUM viram LIMIT; NVL e ISNULL viram COALESCE; GETDATE e SYSDATE viram now() ou CURRENT_TIMESTAMP. Cada troca é simples, mas aparece em centenas de lugares.
• Ordenação de texto. A forma como acentos e cedilha são ordenados depende da configuração de collation e precisa ser definida de propósito.

Nada disso é difícil de resolver. O problema é descobrir depois da virada.

Procedures, triggers e regras dentro do banco

Aqui está o maior risco do projeto. Em muitos sistemas brasileiros antigos, a regra de negócio mora no banco: cálculo de comissão, fechamento de estoque, geração de títulos a receber, validação de pedido. São centenas ou milhares de linhas de T-SQL ou PL/SQL escritas ao longo de anos, muitas vezes sem documentação.

Existem ferramentas que convertem parte desse código automaticamente, como o ora2pg para Oracle e utilitários dos próprios provedores de nuvem. Elas ajudam, mas o resultado precisa ser revisado linha a linha, porque:

• Pacotes do Oracle (packages) não têm equivalente direto e precisam ser reorganizados.
• Tratamento de erro e transações funcionam de forma diferente em cada linguagem.
• Tabelas temporárias, cursores e variáveis de tabela mudam de comportamento.
• SQL dinâmico montado como texto não é convertido por ferramenta nenhuma com segurança.

Esse é o momento de uma decisão de arquitetura: converter a procedure para PL/pgSQL ou tirar a regra do banco e levá-la para a aplicação. Converter é mais rápido e mantém o sistema parecido. Levar para a aplicação dá mais trabalho agora, mas deixa a regra testável, versionada e independente de banco. A escolha raramente é tudo ou nada: procedures de carga e manutenção costumam ser convertidas, regras de negócio centrais costumam valer a reescrita. É a mesma lógica de decidir entre reescrever ou refatorar um sistema legado, aplicada a cada bloco de código.

Os jobs agendados também entram aqui. O SQL Server Agent e o agendador do Oracle executam rotinas noturnas que ninguém lembra que existem. No PostgreSQL, isso vai para uma extensão de agendamento, como o pg_cron, ou para um agendador fora do banco, e cada rotina precisa ser listada antes.

Relatórios e integrações que dependem do banco

O banco raramente é usado só pelo sistema principal. Ao longo dos anos, outros pontos passam a ler e escrever direto nele:

• Relatórios em ferramentas como Crystal Reports, Reporting Services ou planilhas conectadas por ODBC, com SQL escrito à mão.
• Painéis de BI que leem tabelas diretamente.
• Integrações com e-commerce, transportadora, banco ou outro sistema da empresa, feitas por conexão direta, linked server ou pacotes de carga.
• Scripts de exportação para contabilidade, folha ou fiscal rodando em algum servidor esquecido.

Cada um desses pontos precisa ser encontrado, convertido e testado. A forma mais confiável de achar todos é olhar o próprio banco: quais usuários se conectam, de quais máquinas, em que horários. Uma semana de registro de conexões costuma revelar integrações que não estavam em nenhuma lista.

Vale aproveitar a migração para reduzir o acesso direto. Relatórios podem passar a ler uma réplica ou uma base analítica, e integrações podem passar por uma API, o que evita que a próxima mudança de banco tenha o mesmo tamanho.

Testes de desempenho e de resultado

Um banco migrado precisa passar por dois testes diferentes, e os dois são obrigatórios.

Teste de resultado

O mesmo dado precisa gerar o mesmo número. A prática que funciona:

1. Rodar os dois bancos em paralelo com a mesma carga de dados.
2. Comparar contagens e somas por tabela: quantidade de registros, soma de valores, maior e menor data.
3. Comparar os relatórios críticos lado a lado: faturamento do mês, posição de estoque, contas a receber, comissões.
4. Executar os processos de fechamento nos dois ambientes e conferir o resultado.

Qualquer diferença é investigada até a causa, que quase sempre é uma das diferenças de comportamento listadas acima.

Teste de desempenho

O PostgreSQL é rápido, mas consultas otimizadas para outro banco nem sempre continuam rápidas. Índices que o SQL Server usava de um jeito podem precisar ser recriados de outro, e consultas com dicas (hints) do Oracle ou do SQL Server perdem essas dicas, porque o PostgreSQL não tem esse recurso nativo e decide o plano sozinho a partir das estatísticas.

O teste deve usar volume real de dados e as operações mais pesadas do dia a dia: fechamento de mês, emissão em lote, relatórios grandes, horário de pico. O método é o mesmo de um diagnóstico de performance de sistema lento: medir antes, medir depois e atacar as consultas que mais pesam, não as que parecem piores.

Plano de virada com volta segura

A virada não deve ser um salto sem rede. Um plano razoável tem estas etapas:

1. Inventário completo: tabelas, procedures, triggers, jobs, relatórios, integrações e conexões.
2. Decisão por bloco: o que converte, o que reescreve na aplicação, o que desliga por falta de uso.
3. Conversão e carga em homologação, repetida quantas vezes for preciso até ficar previsível.
4. Testes de resultado e desempenho com dados reais e validação dos usuários-chave.
5. Ensaio da virada: cronometrar a carga final e o roteiro completo, com a equipe que vai executar no dia.
6. Janela de virada em período de baixo movimento, longe de fechamento de mês e de datas fiscais.
7. Caminho de volta definido: até que ponto é possível retornar ao banco antigo, com que dados e em quanto tempo.
8. Acompanhamento reforçado nos primeiros dias, com conferência diária dos números críticos.

O caminho de volta é a parte que mais se esquece. Se depois da virada o sistema passa a gravar só no PostgreSQL, voltar significa perder ou reprocessar o que foi feito. Por isso, em sistemas críticos, avalia-se manter replicação reversa por alguns dias ou migrar módulo por módulo, de forma que cada etapa tenha volta simples.

Quanto ao prazo, depende quase todo do volume de lógica dentro do banco. Um sistema com pouca procedure e poucas integrações pode migrar em semanas; um ERP com anos de regra em PL/SQL pode levar meses. A estimativa honesta só sai depois do inventário.

Checklist rápido para decidir

• O custo de licença e suporte dos próximos anos é relevante para o caixa da empresa?
• Existe plano de levar o sistema para a nuvem ou trocar de infraestrutura?
• Quanto da regra de negócio está em procedures e triggers?
• Quantos relatórios e integrações acessam o banco diretamente?
• Há tempo e pessoas para testar em paralelo antes da virada?
• O sistema vai passar por outra modernização em breve que possa ser feita junto?

Se as duas primeiras respostas são "sim" e as do meio indicam pouca lógica no banco, a migração tende a se pagar rápido. Se há muita regra no banco e nenhum plano de nuvem, talvez valha começar tirando a regra do banco e decidir a troca depois.

Perguntas frequentes

O PostgreSQL é gratuito para uso comercial?

Sim. O PostgreSQL é distribuído sob uma licença de código aberto permissiva, que permite uso comercial sem cobrança de licença. Os custos que continuam existindo são de infraestrutura, operação e suporte e, na nuvem, do serviço gerenciado, que cobra pela máquina e pelo armazenamento, não por licença do banco de dados.

O PostgreSQL aguenta o volume de um ERP que hoje roda em Oracle ou SQL Server?

Em geral, sim. O PostgreSQL é maduro e usado em sistemas críticos no mundo todo. O cuidado está nas consultas otimizadas para o banco anterior, que podem precisar de novos índices ou reescrita, já que o PostgreSQL não usa hints nativamente. Por isso o teste de desempenho com volume real de dados é obrigatório antes da virada.

Quanto tempo leva migrar SQL Server ou Oracle para PostgreSQL?

Depende quase todo do volume de lógica dentro do banco. Um sistema com poucas procedures e integrações pode migrar para PostgreSQL em semanas; um ERP com anos de regras em PL/SQL ou T-SQL pode levar meses. A estimativa honesta só sai depois do inventário de tabelas, procedures, jobs, relatórios e conexões.

Existe ferramenta que converte procedures do Oracle para PostgreSQL automaticamente?

Existem ferramentas, como o ora2pg e utilitários dos provedores de nuvem, que convertem parte do código do Oracle para PostgreSQL. O resultado precisa ser revisado linha a linha, porque packages, tratamento de erro, cursores e SQL dinâmico não têm conversão automática segura. Em muitos casos, vale levar a regra de negócio para a aplicação.

Preciso mudar o código da aplicação ao trocar o banco para PostgreSQL?

Quase sempre, em algum grau. O esforço depende de quanto SQL específico do SQL Server ou do Oracle está espalhado no código. Funções como TOP, ROWNUM, ISNULL e GETDATE precisam de equivalentes no PostgreSQL, e diferenças de maiúsculas, datas e texto vazio podem mudar resultados. Testes comparando os dois bancos revelam esses pontos.

Como a Pervian Tech trabalha migração de banco

Na Pervian Tech, começamos pelo inventário: levantamos estrutura, procedures, jobs, relatórios e todas as conexões que chegam ao banco, e transformamos isso num mapa de esforço por bloco. Com esse mapa, o gestor decide com dados se a migração vale agora, depois ou em partes. Esse diagnóstico inicial é gratuito.

A partir dele, desenhamos a migração sob medida dentro do nosso trabalho de arquitetura de software: o que converter, o que reescrever, como testar em paralelo e como virar com caminho de volta. Quando a troca de banco faz parte de uma renovação maior do sistema, ela entra no projeto de modernização de sistemas legados. Outros textos sobre decisões técnicas estão em engenharia.

O cronograma é definido depois do diagnóstico, e o investimento é sob consulta, porque depende do volume de lógica no banco e do número de sistemas conectados. Se a renovação de licença está chegando e a dúvida é se dá para sair, conte como o seu banco é usado hoje.