The migration ran clean, but the schema was wrong. A missing new column made the system stall, and every query burned unnecessary CPU cycles. You saw it in the logs before the alerts started. The fix was obvious. The execution needed to be exact.
Adding a new column sounds trivial until you factor in database load, indexes, null constraints, and deployment windows. In production, every schema change is a change to the heartbeat of the system. Fail once, and you face downtime or corrupted data.
Start by defining the new column with its proper data type. Avoid generic types and choose the smallest type that fits the data. If it must be unique, declare the constraint now to prevent duplicates later. Always decide the default value before adding the column to prevent null insertions that break dependent logic.
In large tables, adding a new column without locking can save hours of degraded performance. Use online DDL operations if the database supports them. For MySQL, consider ALGORITHM=INPLACE where possible. For PostgreSQL, adding a column with a constant default writes no data until the first update, keeping the operation fast.