Você precisa preencher uma coluna nova em duzentos milhões de linhas existentes em produção. Como você roda isso?

Nunca como um único comando update. Adicione a coluna como nullable sem reescrita por default, depois preencha em lotes pequenos ordenados pela chave primária, comitando cada lote, com uma pausa curta entre eles e uma checagem do atraso de replicação. Torne o job retomável registrando o progresso, rode fora do pico, e faça a aplicação já gravar a nova coluna em linhas novas e atualizadas para que o backfill só precise alcançar o histórico.

Um update tocando duzentos milhões de linhas segura locks, gera uma quantidade enorme de write ahead log e empurra as réplicas tão para trás que as leituras começam a servir dados velhos, então o site sofre mesmo sem nada ter caído. Em vez disso eu adiciono a coluna como nullable, o que é barato num Postgres moderno porque não reescreve a tabela, e faço o deploy primeiro da mudança da aplicação que preenche aquilo em todo insert e update. Isso significa que o backfill só precisa lidar com o histórico, e o histórico não se move. Depois o job percorre a chave primária em lotes de alguns milhares, comita cada lote, registra o último id concluído para conseguir retomar após um reinício, e pausa se o atraso de replicação ou a carga do banco cruzarem um limite. Eu rodo com limite de taxa, e não o mais rápido possível. Quando termina eu verifico com contagens e conferências por amostragem que nada ficou nulo, depois viro as leituras para a nova coluna atrás de uma flag, e só depois disso adiciono a constraint not null, validada separadamente para não segurar um lock longo.