Rows stretch endlessly. You need a new column. You add it, but the data shifts, the indexes break, and queries slow to a crawl. This is the moment where decisions matter.
A new column changes your schema. It changes storage patterns, indexes, and query paths. Done well, it improves functionality without hurting performance. Done poorly, it leads to downtime, cost spikes, and bad data.
Before adding a new column, decide on its type. Pick the smallest data type that works. Use integer instead of bigint when possible. Use timestamps with or without time zone depending on your requirements. Keep constraints tight. Null defaults may seem harmless but can complicate migrations later.
For large tables, add a new column in a controlled way. In PostgreSQL, adding a column with a default value rewrites the entire table. This locks writes and can block reads. Adding the column first as NULL, then backfilling in batches, avoids long locks. For MySQL, watch for table rebuilds. Online schema change tools like pt-online-schema-change or gh-ost can minimize impact.