Deletes em cascata grandes podem transformar migração de schema em indisponibilidade

O problema descrito pela PlanetScale nasce de como o Postgres executa um ON DELETE CASCADE grande. Ele emite DELETEs para as linhas correspondentes em todas as tabelas filhas, gerando tuplas mortas, atualizações de índice e WAL, tudo na mesma transação. Durante esse tempo, segura RowExclusiveLock em cada tabela envolvida.

Uma migração simples, como adicionar uma coluna nullable, pede AccessExclusiveLock. Ela não começa até o delete terminar, e as queries novas (o exemplo é customer_users) se enfileiram atrás dela. O resultado é timeout de escritas em quase tudo. Uma mitigação é definir um lock_timeout curto na migração e tentar de novo. Outros riscos citados: centenas de gigabytes de WAL em uma única transação, o que deixa outras transações esperando na replicação síncrona, e foreign keys sem índice, que causam seq scan em deletes de uma única linha. Na replicação lógica nativa, o subscriber roda com session_replication_role = replica, então não dispara checagens nem cascades, e filhos não publicados ficam órfãos. A alternativa proposta é o soft delete com limpeza em lotes, em horário de baixo tráfego, mantendo transações de centenas a poucos milhares de linhas.

O tema conversa com a cobertura anterior. Em 15 de junho de 2026, o CEVIU noticiou "No PostgreSQL, exclusão em larga escala só escala com DROP TABLE, não com DELETE", sobre o custo de DELETEs grandes. Agora a fonte mostra que o cascade é um caso em que essa saída não se aplica com facilidade, e que o caminho é o soft delete com lotes. Em 12 de outubro de 2026, o CEVIU também publicou "Migrações de Schema em PostgreSQL sem Downtime: Estratégias Essenciais para Produção". A notícia atual mostra um modo concreto de essa migração falhar: o lock esperando atrás de uma transação longa.

Para quem opera Postgres em produção, a leitura é que o risco não está só na migração, mas na combinação dela com qualquer transação longa. Vale revisar o grafo de foreign keys com cascade, conferir índices nas colunas referenciadoras e padronizar lock_timeout com retry no pipeline de migração. Para quem replica logicamente, é preciso checar se toda a árvore de FKs está publicada.