The migration failed at 03:12. The log showed one error: “Cannot add column without default value.” Everyone knew the fix, but the damage was already done.
Adding a new column should be simple. In reality, it’s where databases break under load, queries slow, and data consistency risks spike. Whether you work with PostgreSQL, MySQL, or a distributed system, the principles are the same: plan the new column, choose types intentionally, and handle defaults with precision.
A new column changes the schema contract. It affects every read, write, and index path touching that table. Avoid implicit conversions. Declare data types explicitly. Choose NULL or NOT NULL based on real requirements, not just habit. If you need a default value, set it with a migration that won’t lock the whole table.
On high-traffic tables, always test the schema change on a staging environment that mirrors production scale. For PostgreSQL, use ADD COLUMN with NULL where possible, then backfill in small batches. For MySQL, check if your engine supports instant DDL; if not, make changes during low traffic windows or use an online schema change tool.