Vous devez remplir une nouvelle colonne sur deux cents millions de lignes existantes en production. Comment lancez-vous ça ?

Jamais avec une seule instruction update. Ajoutez la colonne en nullable sans réécriture par défaut, puis remplissez par petits lots triés par clé primaire, en validant chaque lot, avec une courte pause entre eux et une vérification du retard de réplication. Rendez le travail reprenable en enregistrant la progression, lancez-le en heures creuses, et faites écrire la nouvelle colonne par l'application pour les lignes créées et modifiées, pour que la reprise n'ait à traiter que l'historique.

Un update touchant deux cents millions de lignes tient des verrous, génère une quantité énorme de journal des écritures, et pousse les réplicas si loin derrière que les lectures se mettent à servir des données périmées, donc le site souffre même si rien n'a planté. À la place, j'ajoute la colonne en nullable, ce qui est peu coûteux sur un Postgres moderne parce qu'il ne réécrit pas la table, et je déploie d'abord le changement applicatif qui la remplit à chaque insertion et à chaque mise à jour. Ça veut dire que la reprise n'a que l'historique à traiter, et l'historique ne bouge pas. Ensuite le travail parcourt la clé primaire par lots de quelques milliers, valide chaque lot, enregistre le dernier identifiant terminé pour pouvoir reprendre après un redémarrage, et fait une pause si le retard de réplication ou la charge de la base dépasse un seuil. Je le lance avec une limitation de débit plutôt qu'à fond. Quand il finit, je vérifie par comptages et sondages qu'il ne reste rien à null, puis je bascule les lectures vers la nouvelle colonne derrière un flag, et seulement après j'ajoute la contrainte not null, validée séparément pour ne pas prendre un verrou long.