No PostgreSQL, exclusão em larga escala só escala com DROP TABLE, não com DELETE

O DELETE no PostgreSQL não apaga dados, ele marca tuplas como mortas, mantendo versões antigas para garantir isolamento de transações via MVCC. Cada linha carrega os campos xmin e xmax, que definem sua visibilidade. Quando você apaga 10 milhões de linhas, o banco cria 10 milhões de tuplas mortas. Elas só saem do disco com VACUUM, e se houver uma transação longa bloqueando a limpeza, o bloat explode.

TRUNCATE e DROP TABLE ignoram esse ciclo: descartam arquivos físicos em um único passo, sem gerar WAL massivo nem depender de autovacuum. Em benchmarks reais, TRUNCATE em 47 milhões de linhas leva menos de 1 segundo; DELETE leva horas e pode encher o WAL com centenas de GB. Isso não é otimização, é escolha arquitetural: se você precisa excluir em massa, seu schema deve ser feito para trocar partições, não para deletar linhas.

A cobertura anterior de 13 de abril já alertava sobre o acúmulo de dead tuples em filas de jobs, mas tratava como problema operacional secundário. Agora, a recomendação mudou de 'ajuste o autovacuum' para 'reprojete o schema'. O artigo de 20 de abril explicava o MVCC teoricamente, hoje sabemos que essa arquitetura torna DELETE em larga escala tecnicamente inviável em produção. E o benchmark de 1º de maio identificou contenção de lock de tabela como gargalo: agora sabemos que DELETE é um dos principais causadores disso, especialmente em workloads concorrentes.

Desenvolvedores que usam Postgres como fila, log ou armazenamento de séries temporais estão sob risco silencioso: cada DELETE em massa degrada desempenho, aumenta custo de I/O e compromete a replicação. A mudança não é só técnica, é de mentalidade. Trocar uma operação lógica (DELETE) por uma estrutural (DROP PARTITION) exige pensar em particionamento desde o início, usar tabelas temporárias com atomicidade de troca (CREATE TABLE AS + ALTER TABLE ... RENAME TO), e abandonar padrões herdados de bancos que não usam MVCC. É menos sobre escrever SQL e mais sobre projetar ciclos de vida de dados.