Du musst einer Tabelle mit 500 Millionen Zeilen eine Not-Null-Spalte hinzufügen. Wie lieferst du das ohne Downtime aus?

Mach es in Etappen. Füg die Spalte nullable und ohne Default hinzu, sodass die Änderung reines Metadatum ist, deploy Code, der sie auf jedem Pfad schreibt und beim Lesen weiterhin Nulls verträgt, backfill in kleinen Batches mit Pausen, damit Locks und Replikation gesund bleiben, prüf, dass keine Nulls mehr übrig sind, setz dann das Not-Null-Constraint (wo unterstützt separat validiert) und entfern den Fallback-Code. Nie ein einzelnes blockierendes ALTER auf einer Tabelle dieser Größe.

Was ich nicht machen werde, ist ein einzelnes ALTER, das eine Not-Null-Spalte mit Default hinzufügt, denn auf einer älteren Engine schreibt das die ganze Tabelle unter einem exklusiven Lock neu, und der Service ist so lange unten, wie das dauert. Ich expandiere also zuerst: Spalte nullable hinzufügen, was auf modernem Postgres eine Metadatenänderung und praktisch sofort ist. Dann deploye ich Code, der die neue Spalte bei jedem Insert und Update schreibt, beim Lesen aber weiterhin Nulls verträgt, denn während eines rollenden Deploys sind alte und neue Pods gleichzeitig live und ich kann nichts anderes annehmen. Dann der Backfill, in Batches von vielleicht zehntausend Zeilen nach Primary Key, mit einer kurzen Pause dazwischen, während ich das Replikationslag beobachte und langsamer werde, wenn es klettert. Sobald die Null-Zahl bei null ist, setze ich das Constraint, und in Postgres würde ich es als not valid hinzufügen und dann separat validieren, um ein schwächeres Lock zu nehmen. Der letzte Deploy entfernt den Fallback. Jeder Schritt ist für sich zurückrollbar.