Safe database migrations on high-traffic PHP apps?

I've been thinking about zero-downtime database migrations lately after hearing a horror story from another team - they had to roll back a deployment and the database migration took 4 hours to complete. Just sitting there, waiting, hoping it doesn't fail.
I know the expand/contract pattern (expand schema → deploy code → migrate data → contract old schema) is the "right way" to handle breaking changes, but I'm curious what people are actually doing in production.
My current approach:

• Additive changes only (nullable columns, new tables, new indexes with CONCURRENTLY)
• Separate migration deployments from code deployments
• Test migrations against production-sized datasets first
• Always have a rollback plan that doesn't require restoring from backup

This works fine for simple stuff, but I'm curious:

• How many of you actually use expand/contract? Does it feel worth the ceremony for renaming a column or changing a data type?
• Any other patterns you use for handling migrations safely? Especially for high-traffic production systems?
• PostgreSQL-specific tricks? I'm mostly on PG and wondering if I'm missing anything obvious beyond CREATE INDEX CONCURRENTLY.

I'd love to hear what's working (or not working) for you. Especially interested in war stories - the weird edge cases that bit you.

P.S. I wrote about this topic (along with other database scaling techniques) in my latest newsletter issue if you want more details: https://phpatscale.substack.com/p/php-at-scale-17 - but I'm more interested in hearing your experiences here, that might give me inspiration for the next edition.