Adding a new column should be simple. In reality, it can stall deployments, block teams, or cause production downtime. Every choice matters: data type, default values, indexing, constraints, and how the migration runs against live traffic.
In relational databases like PostgreSQL or MySQL, an ALTER TABLE ADD COLUMN can be instant for small tables but dangerous for large ones. For wide tables with millions of rows, blocking writes for even seconds can cause failures upstream. Online schema change tools like pg_online_schema_change or gh-ost can add a column without locking the table, but they bring operational complexity.
A new column in PostgreSQL can often be added cheaply if it’s nullable with no default. Once you set a default or add a NOT NULL constraint, the database may rewrite the table, which is slow. For MySQL, altering an InnoDB table can rebuild the table entirely unless ALGORITHM=INPLACE is available for that change.
Indexing the new column is another choice with high cost. Create the index separately, preferably with CONCURRENTLY in PostgreSQL or ALGORITHM=INPLACE in MySQL. Schedule this during low load to avoid replication lag and query slowdowns.