How would you rename a column on a table with 50 million rows with no downtime?

Expand, migrate, contract. Add the new column, deploy code that writes both and still reads the old one, backfill in throttled batches, then flip reads to the new column in a separate deploy, and only drop the old column once nothing references it. Never combine a schema change and a code cutover in one release, because you lose the ability to roll back cleanly.

A rename is really a sequence of small safe changes rather than one statement. First deploy adds the new column as nullable, which is cheap in Postgres because it does not rewrite the table, and ships code that writes to both columns while still reading the old one. Then I backfill in batches, maybe five thousand rows at a time with a short sleep, watching replication lag and lock waits, so I am never holding a long transaction. Second deploy switches reads to the new column, with the dual write still in place so I can revert instantly if something is wrong. Only after that has been stable for a few days does the third deploy stop writing the old column and drop it. The reason I insist on separate deploys is rollback. If the schema change and the code change ship together, reverting the code leaves the database in a shape the old code cannot read. I also add indexes concurrently and set a lock timeout so a migration fails fast instead of queueing behind a long query and freezing writes.