The schema was live. The queries were in production. One wrong move, and you’d lock rows or drop performance into the floor. But it had to happen.
Adding a new column should be simple, but in real systems, it’s where bad migrations turn into outages. Every database has its own rules. PostgreSQL can add a column with a default instantly in some cases, but not all. MySQL may rebuild the entire table. Even adding a nullable column with no default can still cause replication lag in high-traffic environments. Knowing the impact on storage, indexes, and query plans matters before you run ALTER TABLE.
The safest path is controlled. Test the migration in a staging environment with the same data scale and query load as production. Measure execution time. Analyze the lock type. Use online schema change tools when available (pg_online in Postgres, gh-ost or pt-online-schema-change in MySQL). For large datasets, break the change into steps—first add the nullable column, then backfill in small batches, then add constraints or defaults.