When you add a new column to a table, you’re altering the contract between data and code. Every client reading from that table now has an extra field to ignore, adopt, or break on. Every service writing to that table may need to change its insert logic. The schema migration itself can lock the table, impact response times, or spike CPU on your primary node.
Choosing how to create a new column involves tradeoffs. In PostgreSQL, you can add a column with ALTER TABLE ADD COLUMN in milliseconds if it has no default value or is nullable. But if you set a non-null default, Postgres may rewrite all existing rows, causing large I/O. MySQL and MariaDB have similar patterns but differ with online DDL options through ALGORITHM=INPLACE or ALGORITHM=INSTANT. For distributed databases like CockroachDB, adding a column triggers schema changes propagated across the cluster—safe in theory, but worth monitoring under load.
Indexes tied to a new column add another layer of cost and complexity. Creating them synchronously will block writes; creating them concurrently avoids that but takes longer and risks failed builds. For high-traffic systems, feature flags around schema usage allow gradual rollout—deploy column first, switch writes, then reads, then enforce constraints.