When we add a new column, the cost is more than just storage. Schema migrations can lock tables. They can halt writes. They can break services in production. A single ALTER TABLE command can ripple through every process tied to that table.
The design starts with intent. Every new column must have a defined purpose, data type, and constraints. Decide on NULL vs NOT NULL before you migrate. If you need a default value, define it up front to prevent inconsistent data states.
For relational databases like PostgreSQL or MySQL, adding a column may expand each row’s size. The performance impact depends on row alignment, physical storage, and indexes. Adding indexes as part of the same migration can multiply the cost. Separate these steps when possible.
In distributed systems, schema changes require version coordination. Deploy code that can handle both the old and new schema before running migrations. This approach avoids downtime and supports zero-downtime deployments.