Adding a new column to a production database should be simple: define the schema change, run the migration, update the code. In practice, it is never that clean. A new column alters the contract between data and application. It can break queries, trigger costly table locks, or cause unexpected null handling.
Modern databases offer multiple ways to add a column. In PostgreSQL, ALTER TABLE ADD COLUMN is fast for metadata-only changes, but slow if you need defaults or constraints applied to existing rows. MySQL can handle instant column addition in some versions, but storage engines and collation rules still matter. In distributed SQL systems, adding a column might involve background schema propagation across nodes. Each system has trade-offs.
Before adding a new column, define its type with precision. Choose nullability based on business logic, not default ORM settings. Apply constraints at the database level to prevent invalid data, but remember that adding a NOT NULL column with defaults will rewrite the table in many engines. For large datasets, plan for incremental backfills to avoid prolonged locks or replication lag.