A new column changes the shape of your data. It extends your table. It unlocks queries you could not write before. It adds the field that your feature needs. But in production, adding a column is not just a simple ALTER TABLE. It is an operation with weight.
You consider constraints. Will the new column be nullable? Will it need a default? If the table has millions of rows, backfilling can lock the database or choke throughput. If replication is in play, schema changes can cascade across shards. You choose between instant metadata-only updates or full rewrites, depending on the engine.
In PostgreSQL, an ALTER TABLE ADD COLUMN with no default is fast. Adding a default to existing rows causes a rewrite. In MySQL, adding a column at the end is less costly than inserting one in the middle. In distributed SQL systems, schema changes must often coordinate across nodes to avoid version conflicts.
The new column forces you to handle migrations in application code. You add it. You deploy reading logic that tolerates its absence in older rows. You backfill in batches to avoid locking large tables. You deploy writing logic last. This order prevents downtime and keeps integrity until all nodes are aware of the change.