Uma migração para a nuvem não termina quando o último byte chega à AWS. Ela termina quando a aplicação cumpre suas metas de latência e recuperação, a equipe consegue operá-la às três da manhã, a fatura é explicável e o rollback deixou de ser necessário. No PostgreSQL, mover os dados costuma parecer a parte simples; dependências, rede, extensões, identidade e procedimentos operacionais são onde o cronograma normalmente escapa.
Fábrica de migração: evidência precisa atravessar cada gate
Um gate termina quando existe evidência de aceite. Data no calendário não é evidência.
1. Comece pelos critérios de sucesso
Registre por que a empresa está migrando e transforme o objetivo em critérios mensuráveis: indisponibilidade máxima no cutover, latência p95 e p99, RPO, RTO, teto mensal de custo, requisitos regulatórios e data de desligamento do ambiente antigo. Inventarie cada banco, dono, versão, tamanho, crescimento, TPS de pico, conexões, extensões, jobs, integrações, consumidores de replicação e dependências de backup. Colete pelo menos quatro semanas de carga, incluindo fechamento e processamento em lote.
Construa um grafo de dependências, não uma planilha de servidores
Existe dependência sempre que uma mudança de endpoint, relógio, rede, collation, role ou transação altera outro sistema. Mapeie serviços, ETL, BI, arquivos, aliases de DNS, firewall, certificados, LDAP/AD, cron, exportações e consumidores lógicos. Para cada aresta registre dono, protocolo, direção, frequência, timeout e forma de validação. Esse grafo define a ordem do cutover e evita descobrir depois que um relatório esquecido ainda escreve na origem.
| Baseline | O que coletar | Por que muda o projeto |
|---|---|---|
| Demanda | TPS, concorrência, p95/p99, picos horários e sazonais | Define compute, pool e folga — não a CPU média |
| Mudança | WAL/hora, maiores transações e hot spots de escrita | Determina throughput do CDC e velocidade de convergência |
| Storage | working set, IOPS, throughput, latência, temporários e crescimento | Separa capacidade de performance e revela dependência de burst |
| Operação | tempo de backup/restore, incidentes, vacuum e patches | Transforma RTO e manutenção em restrições testadas |
Erro frequente: dimensionar pelo total de CPU e disco contratado no datacenter. Meça CPU utilizada, pressão de memória, IOPS de leitura e escrita, throughput, latência, arquivos temporários, geração de WAL e sessões simultâneas. Na nuvem os limites são explícitos; a média esconde o pico que decide se o cutover funciona.
2. Escolha o modelo operacional antes da ferramenta
| Destino | Quando faz sentido | Contrapartida |
|---|---|---|
| PostgreSQL no EC2 | Acesso ao SO, extensões não suportadas, agentes próprios ou controle exato da topologia | Sua equipe assume patches, backup, HA, failover e capacidade |
| Amazon RDS for PostgreSQL | PostgreSQL gerenciado, comportamento familiar e menos trabalho operacional | Sem acesso ao SO ou superuser real; valide extensões e rotinas administrativas |
| Aurora PostgreSQL-Compatible | Crescimento de storage, múltiplas réplicas de leitura e alta disponibilidade integrada à AWS | Compatível não significa idêntico; teste planos, extensões, failover e custo com sua carga |
Não escolha Aurora apenas por parecer “mais cloud”, nem EC2 apenas por se parecer com o datacenter. Faça uma prova de conceito com volume e concorrência próximos da produção. O guia da AWS para PostgreSQL no EC2 posiciona esse caminho para cargas que exigem controle completo do banco e do sistema operacional.
3. Construa a fundação antes de levar dados
Prepare AWS Organizations, contas por carga/ambiente, IAM Identity Center, logs centralizados, budgets, padrão de tags e controles preventivos. Desenhe ao menos duas Availability Zones, sub-redes privadas, rotas, security groups, DNS, chaves KMS, rotação no Secrets Manager e conectividade via Site-to-Site VPN ou Direct Connect. Meça o round trip entre aplicação e futuro banco: um banco saudável pode entregar uma experiência péssima se a fase híbrida fizer dezenas de viagens entre datacenter e AWS por requisição.
Modele a latência híbrida explicitamente
Se uma transação executa 20 idas sequenciais ao banco e o link acrescenta 18 ms de RTT, somente a rede adiciona aproximadamente 360 ms antes do tempo das queries. Abertura de conexão, TLS e DNS podem somar mais. Migre componentes tagarelas junto com o banco, reduza chamadas sequenciais, aqueça pools e teste perda de pacotes, não apenas banda. Direct Connect melhora previsibilidade; não remove distância.
4. Escolha a movimentação de dados pelo downtime e pelo risco
- Offline:
pg_dump/pg_restoreé transparente e confiável para bases menores com janela de manutenção. Cronometre restore, criação de índices, constraints eANALYZE, não apenas o dump. - Física: base backup ou streaming replication preserva maior fidelidade ao engine, mas exige compatibilidade de versões e um destino que aceite o método.
- Online: AWS DMS ou replicação lógica nativa combina carga inicial e change data capture (CDC), reduzindo a parada à sincronização final e troca da aplicação.
Em migrações homogêneas, o fluxo do AWS DMS para PostgreSQL usa mecanismos nativos: pg_dump/pg_restore na carga completa e publisher/subscriber para CDC. Mesmo assim, roles, grants, sequences, large objects, extensões, mudanças de DDL e objetos fora das tabelas replicadas precisam de um plano explícito.
Entenda a equação de capacidade do CDC
A replicação só converge quando o throughput sustentado de apply supera a mudança na origem. Se a origem produz 80 MB/s e o destino aplica 100 MB/s, a recuperação teórica é apenas 20 MB/s. Um backlog de 720 GB levaria cerca de dez horas em condições ideais. Transações grandes, índices no destino, LOBs, jitter e validação reduzem essa margem. Separe latência origem→replicador e replicador→destino para localizar o gargalo.
Disciplina de DDL durante CDC: replicação lógica não é serviço de migração de schema. Congele ou coordene DDL, pré-crie objetos compatíveis, sincronize sequences antes de abrir escrita e confirme que triggers e jobs não rodarão duas vezes.
5. Ensaie, valide e torne o rollback executável
Faça pelo menos um ensaio completo e marque o tempo de cada fase. Valide contagem e checksum das tabelas críticas, sequences, constraints, permissões, jobs e testes funcionais. Compare fingerprints, planos, distribuição de latência, cache hit, I/O, locks, autovacuum e lag entre origem e destino. O teste de carga precisa reproduzir distribuição dos dados e configuração do pool, não apenas volume.
- Congele DDL não essencial e confirme a janela de mudança.
- Verifique se a latência do CDC está estável e se não há erros de validação.
- Reduza o TTL do DNS com antecedência; pare escritores ou coloque a aplicação em modo controlado.
- Aguarde o destino alcançar a origem, registre a posição final e sincronize sequences.
- Troque secrets/endpoints, execute smoke tests e abra o tráfego gradualmente.
- Preserve a origem e defina o instante exato a partir do qual voltar deixa de ser seguro.
O rollback deve dizer quem decide, como tratar escritas feitas no novo ambiente, qual endpoint volta e quanto tempo isso leva. “O servidor antigo ainda existe” não é um plano de rollback.
Use gates objetivos de go/no-go
| Gate | Evidência mínima | Exemplo de no-go |
|---|---|---|
| Dados | Tabelas críticas reconciliadas, CDC no limite e sequences verificadas | Diferença sem explicação ou erro de replicação |
| Performance | Jornadas críticas dentro de p95/p99 e folga definida | SQL crítico com regressão de plano não analisada |
| Resiliência | Restore/failover exercitados e reconexão medida | Runbook depende de passo manual sem dono |
| Operação | Dashboards, alertas, acessos, backup e escalonamento validados | Equipe não diagnostica o destino sem ferramenta da origem |
6. Estabilize antes de economizar
Nos primeiros dias, acompanhe saturação, latência por query, mudanças de plano, conexões, WAL, saúde das réplicas, crescimento do storage, backups e comportamento do failover. Só depois faça rightsizing ou compromissos de longo prazo. Uma folga temporária custa menos que um cutover malsucedido; superdimensionamento permanente também não é estratégia.
Como o PG Monitoring ajuda nesta migração
O PG Monitoring funciona como plano de controle técnico durante toda a migração, não apenas depois que a produção mudou. Antes do cutover ele registra fingerprints, distribuição de latência, planos, pressão de conexões, crescimento, vacuum e replicação. No ensaio e na virada mostra o delta origem/destino: qual query mudou de plano, para onde o wait time migrou, se o lag está convergindo e se o novo pool esgota conexões. Depois mantém a janela comparativa enquanto previsão de capacidade e anomalias revelam problemas que um smoke test curto não encontra.
Entrega concreta: use o PG Monitoring para gerar baseline pré-migração, visão de saúde do cutover e relatório de regressões pós-migração. Isso dá ao responsável pelo go/no-go algo mais forte que “os gráficos estão verdes”. Se você planeja PostgreSQL na AWS, fale com nossa equipe sobre um assessment de prontidão e observabilidade.