Postgres Migration Safety Is a Real Operational Concern
A former Cloudflare Postgres platform lead posted a tool for evaluating whether schema migrations are safe, and the thread filled up with war stories. The most upvoted comment wasn't about the DDL itself but about lock queuing: an instant ADD COLUMN that waits behind a long read causes every query behind it to pile up. The fix (lock_timeout plus retry) is well-known in database circles but apparently not well-known enough.
The pattern: as more teams run Postgres at scale without a dedicated DBA, operational knowledge that used to live in a specialist is getting encoded into tooling. This is the same impulse behind tools like pganalyze, Neon's branching, and now this migration safety checker.
The thread also has someone linking their own Go library (onwardpg) for the same problem, which suggests this is a solved-enough problem that multiple independent tools exist, but not solved-enough that people aren't still getting hurt by it.
So what?
If you're running Postgres in production without a dedicated DBA, lock queuing on migrations is probably your biggest unmonitored risk. Set lock_timeout on all migrations and build in a retry loop. The tooling to automate this safety check is now available and worth adding to your deployment pipeline.