Rows are frozen in place, but your product demands change. You need a new column.
A new column is more than storage. It defines meaning. It changes how data flows through your system. In SQL, adding a column is quick:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
The command runs, but the implications run deeper. Database migrations must be safe. Every change to a schema affects queries, indexes, and performance under load. Choosing the right data type for the new column is critical. A wrong choice can lead to type mismatches, broken joins, and slow lookups.
When adding a new column, check for null defaults. Backfilling millions of rows can lock your table or choke throughput. Use NULL where possible, then populate data in batches. Adjust the schema in coordination with your application code. Deploy changes so the new column is read-only until populated, then switch writes on.
In distributed systems, schema changes affect replicas. The new column must propagate cleanly across all nodes. Verify migration scripts on staging with production-sized datasets. Monitor replication lag. Test how queries behave when some rows have empty values.