The table was running hot, queries pushing the database to its edge. You knew the schema had to change. A new column was the answer. Not later. Now.
Adding a new column sounds simple. In production, it isn’t. At scale, it’s a surgical operation. Locks, migrations, data integrity—every choice matters.
In PostgreSQL, ALTER TABLE ADD COLUMN is fast if the column is nullable or has a constant default. The change updates metadata without rewriting the entire table. But adding a non-null column with a default can trigger a full table rewrite, locking writes and reads until completion. In MySQL, ALTER TABLE historically rewrites the table for most schema changes, though newer versions with INSTANT or ALGORITHM=INPLACE modes can avoid this in certain cases.
Before adding a new column in production, measure the impact. On large tables, even a small schema change can cause downtime or replication lag. Test your migration on staging with data that matches production scale. Use transactional DDL where possible, and break changes into steps: