You need to add a non nullable column to a table with 500 million rows. How do you ship that without downtime?

Do it in stages. Add the column as nullable with no default so the change is metadata only, deploy code that writes it on every path while still tolerating nulls, backfill in small batches with pauses so locks and replication stay healthy, verify no nulls remain, then add the not null constraint (validated separately where supported) and remove the fallback code. Never one blocking ALTER on a table that size.

The thing I will not do is one ALTER that adds a not null column with a default, because on an older engine that rewrites the whole table under an exclusive lock and the service is down for as long as that takes. So I expand first: add it nullable, which on modern Postgres is a metadata change and effectively instant. Then I deploy code that writes the new column on every insert and update while still tolerating nulls on read, because during a rolling deploy old and new pods are both live and I cannot assume otherwise. Then the backfill, in batches of maybe ten thousand rows keyed by primary key with a short sleep between them, watching replication lag as it runs and slowing down if lag climbs. Once the null count is zero I add the constraint, and in Postgres I would add it as not valid then validate separately to take a weaker lock. The last deploy removes the fallback. Every step is individually reversible.