Adding a new column to a production table is simple in theory, dangerous in practice. It changes your schema, affects queries, and can break upstream or downstream systems. The impact grows with the size of the table. A careless ALTER TABLE can lock millions of rows, stall writes, and trigger failures in services that expect a different structure.
The safest path starts with planning the exact column type, default values, and nullability. Choosing the wrong type can lead to silent data corruption or expensive migrations later. Keep the column definitions tight: avoid generic text fields when integers, enums, or timestamps are the right fit.
The next step is to manage the migration process. For small tables, an ALTER TABLE ADD COLUMN may take milliseconds. For large datasets, use phased migrations. Add the column without defaults first. Backfill in small batches. Validate every write. Feature-flag the new column usage at the application level so you can roll back without schema changes.