Como você renomearia uma coluna em uma tabela com 50 milhões de linhas sem downtime?

Expandir, migrar, contrair. Adicione a coluna nova, implante um código que escreve nas duas e ainda lê a antiga, preencha em lotes com throttle, depois vire as leituras para a coluna nova em um deploy separado, e só remova a coluna antiga quando nada mais a referenciar. Nunca combine uma mudança de schema e uma virada de código no mesmo release, porque você perde a capacidade de fazer rollback de forma limpa.

Um rename na verdade é uma sequência de mudanças pequenas e seguras em vez de um comando só. O primeiro deploy adiciona a coluna nova como anulável, o que é barato no Postgres porque não reescreve a tabela, e entrega um código que escreve nas duas colunas enquanto ainda lê a antiga. Depois eu preencho em lotes, talvez cinco mil linhas por vez com um sleep curto, observando o atraso de replicação e as esperas por lock, para eu nunca segurar uma transação longa. O segundo deploy vira as leituras para a coluna nova, com a escrita dupla ainda no lugar para eu conseguir reverter na hora se algo estiver errado. Só depois de aquilo ficar estável por alguns dias é que o terceiro deploy para de escrever na coluna antiga e a remove. O motivo de eu insistir em deploys separados é o rollback. Se a mudança de schema e a mudança de código vão juntas, reverter o código deixa o banco em um formato que o código antigo não consegue ler. Eu também crio índices de forma concorrente e configuro um lock timeout para uma migração falhar rápido em vez de ficar na fila atrás de uma query longa e congelar as escritas.