It sounds simple. One altered table, one extra field. But a new column in a production database is never just a schema change. It is a decision point. The wrong move locks tables, drops performance, and forces rollbacks at 3 a.m. The right move makes the system stronger.
A new column changes the shape of your data. In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward, but on large datasets it can cause long locks if you add defaults or constraints. MySQL behaves differently — past versions rewrote the entire table, newer versions under certain engines run it in-place. In distributed databases, schema changes ripple across shards and replicas. If you run migrations without a plan, you risk blocking reads and writes.
Best practice starts with knowing the storage engine and version. Test the migration on a dataset cloned from production. Time the operation. Watch query plans. Avoid adding non-null columns with defaults in a single step. Break it into adding the column null first, then updating values in controlled batches, then adding constraints after the data is ready. This reduces lock times and makes rollbacks simpler.