Adding a new column should be simple. Yet, in production systems under load, mistakes are expensive. A bad migration locks tables. A slow ALTER bloats replication lag. The wrong data type means hours lost in rollback.
The best approach starts with clarity. Define the column name and data type with precision. Make sure the specification matches your current and future queries. Avoid nullable columns unless the data model demands them. Nulls complicate indexing and query plans.
In relational databases like PostgreSQL, adding a new column with ALTER TABLE is straightforward when the column is nullable or has a default. But be aware: adding a column with a non-null default can rewrite the entire table. That will block writes and spike I/O. In high-traffic environments, you want to make this operation instant. Add the column as nullable first, backfill in small batches, then apply the NOT NULL constraint after the data is complete.
In MySQL, the caution is similar but more severe if you’re on an older version without instant DDL. Even with modern MySQL, adding a new column can still impact replication or row formats. Test migrations on a replica before touching production.