Adding a new column to a database is simple in theory, but in production, it can be a fault line. Schema changes touch live queries, indexes, and application code. They can lock tables, block writes, or slow reads. The wrong migration can ripple through an entire system in seconds.
A new column should start with a plan. Choose the correct data type. Decide if it needs to allow NULLs, if it requires a default value, or if it must be indexed. In relational systems like PostgreSQL or MySQL, each choice affects performance, storage, and replication.
For PostgreSQL, adding a nullable column without a default is nearly instant. Adding a non-null column with a default rewrites the table, which can block operations. To avoid downtime, split the change into steps: first add the column as nullable without a default, then backfill data, then set constraints. MySQL behaves differently depending on engine and version; InnoDB may require a table copy for certain changes.
In NoSQL databases, a new column is often a field in documents. This can be low risk, but consistency and indexing still matter. For example, in MongoDB, adding a field to existing documents may require a bulk update if you need deterministic values.