Necesitas rellenar una columna nueva en doscientos millones de filas existentes en producción. ¿Cómo lo ejecutas?

Nunca como una única sentencia update. Añade la columna como nullable sin reescritura por defecto, luego rellena en lotes pequeños ordenados por clave primaria, confirmando cada lote, con una pausa corta entre ellos y una comprobación del retraso de replicación. Haz el proceso reanudable guardando el progreso, ejecútalo fuera de hora punta, y haz que la aplicación escriba la columna nueva en filas nuevas y actualizadas para que el relleno solo tenga que cubrir el histórico.

Un update que toca doscientos millones de filas retiene bloqueos, genera una cantidad enorme de write ahead log y deja a las réplicas tan atrasadas que las lecturas empiezan a servir datos rancios, así que el sitio sufre aunque no se caiga nada. En vez de eso añado la columna como nullable, que en un Postgres moderno es barato porque no reescribe la tabla, y despliego primero el cambio de aplicación que la rellena en cada insert y cada update. Eso significa que el relleno solo tiene que ocuparse del histórico, y el histórico no se mueve. Después el proceso recorre la clave primaria en lotes de unos pocos miles, confirma cada lote, guarda el último id que terminó para poder reanudar tras un reinicio, y se pausa si el retraso de replicación o la carga de la base de datos cruzan un umbral. Lo ejecuto con un límite de velocidad en vez de a toda máquina. Cuando acaba, verifico con conteos y comprobaciones puntuales que no queda nada a null, luego cambio las lecturas a la columna nueva detrás de un flag, y solo después añado la restricción not null, validada aparte para que no tome un bloqueo largo.