Four kinds of ALTER TABLE that cause production migration incidents

A migration that works on an empty local database can still fail or damage data in production, where real rows and application code depend on the existing schema. The article groups risky statements into four categories: destructive operations like dropping columns or primary keys, constraints that fail on existing rows, and renames that break running code. It shows that adding a NOT NULL column with a non-volatile default is fast on PostgreSQL 11 and later, since the default is stored in metadata without a table rewrite. For constraints on large tables, it recommends adding a NOT VALID check constraint, validating it separately to reduce lock impact, and then applying NOT NULL.