Wie würdest du eine Spalte in einer Tabelle mit 50 Millionen Zeilen ohne Downtime umbenennen?

Expand, Migrate, Contract. Leg die neue Spalte an, deploye Code, der beide schreibt und weiterhin die alte liest, backfille in gedrosselten Batches, schalt dann in einem separaten Deploy die Lesevorgänge auf die neue Spalte um, und lösch die alte Spalte erst, wenn nichts mehr darauf verweist. Kombinier nie eine Schemaänderung und eine Code-Umschaltung in einem Release, weil du dann nicht mehr sauber zurückrollen kannst.

Ein Rename ist in Wahrheit eine Folge kleiner sicherer Änderungen und keine einzelne Anweisung. Der erste Deploy legt die neue Spalte als nullable an, was in Postgres billig ist, weil die Tabelle nicht neu geschrieben wird, und liefert Code aus, der in beide Spalten schreibt und weiterhin die alte liest. Dann backfille ich in Batches, vielleicht fünftausend Zeilen auf einmal mit einer kurzen Pause, mit Blick auf Replication Lag und Lock Waits, damit ich nie eine lange Transaktion halte. Der zweite Deploy schaltet die Lesevorgänge auf die neue Spalte um, mit weiterhin aktivem Dual Write, damit ich sofort zurückkann, wenn etwas nicht stimmt. Erst wenn das ein paar Tage stabil war, stoppt der dritte Deploy das Schreiben der alten Spalte und löscht sie. Der Grund, warum ich auf getrennte Deploys bestehe, ist Rollback. Gehen Schemaänderung und Codeänderung zusammen raus, hinterlässt ein Zurückrollen des Codes die Datenbank in einer Form, die der alte Code nicht lesen kann. Ich lege Indizes außerdem concurrently an und setze ein Lock-Timeout, damit eine Migration schnell scheitert, statt sich hinter einer langen Query einzureihen und Schreibvorgänge einzufrieren.