You need to populate a new column across two hundred million existing rows in production. How do you run that?

Never as a single update statement. Add the column as nullable with no default rewrite, then backfill in small batches ordered by primary key, committing each batch, with a short sleep between them and a check on replication lag. Make the job resumable by recording progress, run it off peak, and have the application write the new column for new and updated rows so the backfill only has to catch history.

One update touching two hundred million rows holds locks, generates an enormous amount of write ahead log, and pushes replicas so far behind that reads start serving stale data, so the site suffers even though nothing crashed. Instead I add the column as nullable, which is cheap on a modern Postgres because it does not rewrite the table, and I deploy the application change that populates it on every insert and update first. That means the backfill only has to handle history, and history is not moving. Then the job walks the primary key in batches of a few thousand, commits each batch, records the last id it finished so it can resume after a restart, and pauses if replication lag or database load crosses a threshold. I run it with a rate limit rather than as fast as possible. When it finishes I verify with counts and spot checks that nothing is left null, then flip reads to the new column behind a flag, and only after that add the not null constraint, validated separately so it does not take a long lock.