Comment renommeriez-vous une colonne sur une table de 50 millions de lignes sans interruption de service ?

Expansion, migration, contraction. Ajoutez la nouvelle colonne, déployez du code qui écrit les deux et lit encore l'ancienne, remplissez par lots régulés, puis basculez les lectures vers la nouvelle colonne dans un déploiement séparé, et ne supprimez l'ancienne colonne qu'une fois que plus rien ne la référence. Ne combinez jamais un changement de schéma et une bascule de code dans une seule release, parce que vous perdez la capacité de revenir en arrière proprement.

Un renommage, c'est en réalité une séquence de petits changements sûrs plutôt qu'une seule instruction. Le premier déploiement ajoute la nouvelle colonne en nullable, ce qui coûte peu dans Postgres puisque ça ne réécrit pas la table, et livre du code qui écrit dans les deux colonnes tout en lisant encore l'ancienne. Ensuite je remplis par lots, peut-être cinq mille lignes à la fois avec une courte pause, en surveillant le retard de réplication et les attentes de verrou, pour ne jamais tenir une longue transaction. Le deuxième déploiement bascule les lectures vers la nouvelle colonne, avec la double écriture toujours en place pour pouvoir revenir instantanément si quelque chose cloche. Ce n'est qu'après quelques jours de stabilité que le troisième déploiement arrête d'écrire l'ancienne colonne et la supprime. La raison pour laquelle j'insiste sur des déploiements séparés, c'est le retour arrière. Si le changement de schéma et le changement de code partent ensemble, revenir sur le code laisse la base dans une forme que l'ancien code ne sait pas lire. J'ajoute aussi les index en mode concurrent et je pose un lock timeout pour qu'une migration échoue vite au lieu de faire la queue derrière une longue requête et de geler les écritures.