The schema was wrong, and the product team needed a new column. No migration script was ready. Deadlines were approaching. The database stood still, waiting.
Adding a new column sounds simple, but in production it can be a fault line. The task means more than altering a table. It means thinking about backward compatibility, locking, replication lag, and how client code will behave when it sees nulls.
First, review the schema. Identify the table. Confirm the column name, data type, and default behavior. Avoid reserved keywords. If the column is not nullable, prepare default values or a fill strategy.
In PostgreSQL, the basic syntax is:
ALTER TABLE customers ADD COLUMN status TEXT DEFAULT 'active';
If the table is large, be aware that certain operations can lock writes. PostgreSQL allows adding nullable columns without a full table rewrite, but setting a default that is not null can cause a table-wide write. MySQL behaves differently; in some versions, adding a column can block reads and writes until complete.