Adding a new column to a production database should be simple. One statement. One deploy. But schema changes in live systems can be dangerous. Rows are large. Tables are locked. Downtime is costly. The right approach depends on the database, the size of the table, the indexes in play, and the tolerance for blocking writes.
In PostgreSQL, ALTER TABLE ADD COLUMN is transactional and fast if the column has no default and no NOT NULL constraint. Adding a default forces a rewrite, which can lock the table and cause minutes or hours of downtime. If you must set a default, add the column first without one, then backfill in small batches. Once data is filled, add constraints in a separate migration.
In MySQL, adding a new column can be instant with ALGORITHM=INSTANT in supported versions, but older versions require a rebuild. This can block reads and writes for long periods. Use tools like gh-ost or pt-online-schema-change to apply changes online without locking the table.
For distributed databases, the problem is more complex. Schema changes must propagate to all nodes. Some systems offer schema versioning APIs. Others require rolling restarts. Always verify replication lag, backlog, and cluster health before migrating.