PlanetScale lança Heroku Migrator para migrar bancos de vários terabytes do Heroku sem logical replication

A PlanetScale atacou um problema específico: os planos padrão do Heroku Postgres não oferecem acesso ao WAL nem logical replication. Segundo a empresa, a replicação lógica só chegou ao Heroku Postgres Advanced em outubro de 2026, o que não ajuda quem está nos planos padrão (e exigiria uma migração extra para o tier Advanced). Sem slot de replicação, o caminho online restante é a replicação baseada em triggers, e é isso que o Heroku Migrator faz, usando o Bucardo. Ele instala triggers bucardo_delta em cada tabela de origem, registra inserts, updates e deletes em tabelas de delta e track, faz um COPY único e depois aplica os deltas no destino.

O ganho de velocidade vem da divisão em duas fases. Antes do COPY, o migrator derruba índices secundários e únicos no destino, mantendo as chaves primárias, que o Bucardo precisa para aplicar mudanças. Depois da cópia, pausa a replicação e reconstrói os índices com workers paralelos (maintenance_work_mem de 1GB e 2 workers paralelos de manutenção). Num caso relatado, a cópia saltou de cerca de 60 GB/h para quase 300 GB/h, a reconstrução levou cerca de 2 horas e o processo todo ficou umas 2,5 vezes mais rápido. A empresa também ajustou transaction_timeout=0 nas conexões do Bucardo e configurou TCP keepalives para que conexões derrubadas virem erro em cerca de um minuto, não travamento. Restrições: toda tabela replicada precisa de chave primária ou índice único, e o schema fica congelado durante a migração. Para bases a partir de 500 GB, a recomendação é rodar o migrator numa instância EC2 de alto desempenho.

Para quem opera banco no Heroku e não pode ter horas de downtime, a ferramenta tira a necessidade de produto de terceiros ou de subir de tier só para ter logical replication. Na prática, o trabalho pesado vira planejamento: achar tabelas sem chave primária, congelar DDL (inclusive auto-migrations do framework e manutenção do pg_partman) e dimensionar onde o migrator roda. É uma leitura editorial, mas o uso de triggers tende a exigir mais atenção operacional que replicação via WAL, então vale ensaiar o cutover e usar a etapa de verificação.