Migração de PostgreSQL com replicação lógica: como mover o banco com poucos segundos de downtime

A fonte descreve um mesmo procedimento para dois cenários: upgrade de major version (a partir do PostgreSQL 10) e migração de RDS, Cloud SQL, Azure ou servidor próprio para a Aiven. Só muda a origem. O destino roda em paralelo, recebe o stream das alterações, e o cutover leva o tempo de drenar as últimas mudanças e reconectar a aplicação. O servidor antigo fica intacto como rollback. O pg_upgrade, por comparação, é rápido, mas deixa o banco indisponível durante a execução e só vai para frente. Voltar exige restaurar backup ou fork, com perda das escritas feitas depois.

O ponto técnico central é o que a replicação lógica não carrega. DDL não trafega, então o schema precisa existir no destino antes da primeira linha (a fonte usa pg_dump --schema-only e recomenda congelar DDL durante a migração). Large objects ficam no catálogo pg_largeobject e fora da publicação, então são copiados com pg_dump -b no cutover, o que preserva os oids. Sequences precisam de setval() até o PostgreSQL 19, que passa a replicá-las. Tabelas sem chave primária pedem REPLICA IDENTITY FULL, ou melhor, uma chave primária. Depois do cutover, derrube o replication slot: um slot órfão retém WAL até encher o disco. A fonte também lembra que o PostgreSQL 14 sai de suporte em 12 de novembro de 2026 e que o PostgreSQL 19 tem disponibilidade geral prevista para 19 de novembro de 2026.

O tema já vinha sendo coberto. Em 28 de setembro de 2026, o CEVIU publicou "Replicação Lógica do PostgreSQL: Uma Década de Evolução e Inovação em Movimentação de Dados", sobre a trajetória do recurso. Em 12 de outubro de 2026, veio "Migrações de Schema em PostgreSQL sem Downtime: Estratégias Essenciais para Produção", que trata da separação de etapas como expansão de schema, backfill, troca de tráfego e limpeza. Em 15 de outubro de 2026, "Atualizações de Versão com Zero Downtime via Replicação Lógica" mostrou uma demonstração com Docker de clusters antigo e novo coexistindo. A matéria de agora fecha o ciclo com um roteiro numerado de scripts, verificações por contagem e hash e os cuidados de DDL, large objects e sequences.

Para quem opera PostgreSQL em produção, o recado é prático: o risco de um upgrade não está na cópia dos dados, mas no que fica de fora dela. Com o fim de suporte do PostgreSQL 14 se aproximando, a escolha entre pg_upgrade e replicação lógica vira decisão de janela de manutenção e de plano de rollback. Se a janela tolera um minuto, o in-place basta. Se não tolera, vale ensaiar a replicação lógica antes.