A new column changes the shape of your dataset and the logic of your code. It alters queries, APIs, and downstream consumers. Name it poorly, and future migrations hurt. Add it in the wrong order, and indexes slow to a crawl. Handle it wrong in production, and you risk downtime or corrupted state.
In SQL, you use ALTER TABLE ... ADD COLUMN. In PostgreSQL, it’s near-instant unless you set a default on an existing row set. MySQL needs storage engine awareness. SQLite rewrites the table under the hood. These differences matter in high-traffic systems where migrations run live, not in staging.
Plan the schema change. Choose the data type that matches the domain. For timestamps, decide on UTC storage. For strings, pick a sane length and collation. If the new column is for relationships, set foreign keys or constraints early, or deal with broken joins later.