Uma nova tela precisa de um campo adicional. A alteração parece pequena, mas a tabela tem histórico importante, integrações antigas e consultas acontecendo enquanto o deploy é executado. O risco está na convivência entre versões e na forma como o banco aplica a mudança.
Uma migração segura precisa considerar compatibilidade, bloqueios, volume de dados e recuperação. Ter um arquivo SQL versionado é importante, mas não demonstra que a operação pode ser executada sem impacto em produção.
“Sem downtime” é uma meta que precisa de evidência
O comportamento de uma alteração depende do banco, da versão, do comando e do estado da tabela. A documentação do PostgreSQL sobre ALTER TABLE descreve níveis de bloqueio e particularidades das operações. Não existe uma regra universal segundo a qual adicionar um campo ou índice seja sempre instantâneo.
Antes de prometer continuidade, simule a mudança com volume e concorrência representativos. Um banco de teste com dez linhas não revela o efeito em uma tabela grande. Também verifique transações longas, limites de tempo e espaço disponível para a operação.
Expanda, migre e só depois remova
Uma estratégia prática é dividir a alteração em fases compatíveis. Primeiro, adicione a estrutura nova sem eliminar a antiga. Depois, publique código que possa conviver com ambas. Em seguida, transfira ou preencha dados em lotes e valide o resultado. A remoção fica para uma etapa posterior, quando os consumidores antigos não dependem mais dela.
Em um exemplo hipotético, um sistema substitui o campo textual status por uma referência a uma tabela de estados. Renomear ou apagar o campo imediatamente pode quebrar exportações e integrações. Uma transição gradual permite atualizar esses consumidores e conferir divergências antes do corte final.
| Fase | Objetivo | Pergunta de liberação |
|---|---|---|
| Expandir | Adicionar estrutura compatível | O código atual continua funcionando? |
| Adaptar | Preparar leitura e escrita | Há divergência entre representações? |
| Migrar | Atualizar o histórico | O processo pode ser pausado e retomado? |
| Validar | Conferir consistência | Totais, vínculos e exceções foram revisados? |
| Contrair | Retirar estrutura antiga | Todos os consumidores foram atualizados? |
Essa sequência é uma recomendação de planejamento, não um comando pronto para qualquer banco. Detalhes como índices, constraints e validação devem ser desenhados por quem conhece o ambiente.
Backfill não deve competir sem limite com a operação
Preencher milhões de registros de uma vez pode pressionar disco, replicação e concorrência. Trabalhar em lotes permite acompanhar o avanço e reduzir a intensidade quando a aplicação começa a degradar. O tamanho do lote precisa ser medido, não copiado de um tutorial.
O processo deve registrar progresso com um critério estável. Se ele reiniciar, precisa saber o que já foi concluído e poder repetir etapas sem corromper os dados. Também é importante decidir como tratar registros novos enquanto o histórico antigo está sendo atualizado.
Não use somente contagem total para validar. Um lote pode terminar com a quantidade esperada e valores errados. Confira amostras de casos extremos, vínculos, somas de negócio e registros que não puderam ser convertidos. Exceções devem aparecer em uma lista tratável.
Reverter código não reverte dados automaticamente
Uma versão anterior da aplicação pode não entender a nova representação. E um comando de retorno pode perder informações que só existem no formato novo. Por isso, o plano de recuperação precisa separar voltar o software, interromper uma migração e restaurar dados.
Backup é indispensável quando aplicável, mas sua existência não prova recuperação. Considere tempo para restaurar, mudanças ocorridas após a cópia e conciliação com integrações externas. Para alterações destrutivas, uma janela controlada pode ser mais responsável do que prometer ausência de interrupção sem teste.
Combine a mudança com quem depende do banco
Relatórios, rotinas financeiras, automações, exportações e agentes podem usar o campo alterado. Inventarie esses consumidores antes do deploy. A ausência de erro na tela principal não significa que a migração foi bem-sucedida para a operação inteira.
Defina observação após a publicação. A equipe precisa saber quais sinais indicam problema, quem decide interromper e qual é o ponto de retorno seguro. Uma mudança que exige acompanhamento não deve ser publicada sem alguém responsável pela janela.
Checklist antes da execução
- Identificar versão do banco e comportamento do comando.
- Testar bloqueio, duração e consumo com dados representativos.
- Mapear leitores e escritores do esquema afetado.
- Planejar transição compatível entre versões.
- Definir lotes, retomada e validação do histórico.
- Documentar recuperação e limites de reversão.
- Acompanhar erros e indicadores de negócio após o deploy.
Perguntas frequentes
Toda alteração exige parar o sistema?
Não. Algumas permitem transição compatível. A decisão depende da operação concreta e dos testes; não pode ser tomada apenas pelo tamanho aparente da mudança.
Posso confiar no comando de rollback da ferramenta?
Ele pode ajudar, mas precisa ser revisado quanto à preservação de dados e compatibilidade. Um rollback gerado não substitui um plano de recuperação testado.
Qual é o melhor horário para migrar?
O período de menor impacto, com equipe disponível para acompanhar e recuperar. Baixo tráfego sem suporte pode ser uma escolha pior do que uma janela assistida.
Referência e próximo passo
Consulte a documentação de ALTER TABLE do PostgreSQL para os detalhes do comando e da versão em uso. O roteiro de implantação é uma proposta editorial.
Para revisar um sistema existente antes de evoluí-lo, use o guia de auditoria técnica e conheça o desenvolvimento da A2CR.
