Adding a new column sounds simple. The reality is that schema changes can break production systems, lock tables, or cause downtime. A poorly executed change on a high-traffic system can cascade into a critical outage. That is why the process needs precision.
Before adding a new column, confirm the change in version control. Tag the migration so it is tied to a specific release. Decide if the column will be nullable or require a default value. In large datasets, adding a non-nullable column with no default can lock the table for too long. Use defaults with care—once set, they may be difficult to change without a rewrite.
For relational databases like PostgreSQL or MySQL, small schema changes may still trigger a full table rewrite depending on data types. If possible, use ALTER TABLE ... ADD COLUMN with a default of NULL, then backfill data in small batches. After that, apply constraints in a separate operation. This reduces locking time and the risk of blocking concurrent reads and writes.