Adding a new column to a production database is simple in theory, but in practice it can bring a system to its knees. The wrong approach locks tables, blocks other writes, and slows queries. The right approach makes the change invisible to users and safe for the system.
A new column changes the schema. That means updating the definition of a table without breaking the contract it has with the rest of the application. In relational databases, this is done with an ALTER TABLE statement. In NoSQL systems, the process depends on the way documents or key-value pairs are stored and retrieved. The operation must be planned for indexing, default values, and how old rows will handle the new field.
In PostgreSQL, adding a nullable new column without a default is fast because it only updates metadata. Adding a default value forces a table rewrite and can lock large tables. In MySQL, the storage engine determines whether the operation runs online or needs exclusive locks. DBAs often stage the change: first add the column as nullable, then backfill in small batches, and finally apply constraints.
Migrations in production should be repeatable, backward-compatible, and reversible. This means scripts should run the same way in test and staging environments and must not assume instant propagation of the schema. Applications should tolerate both the old and new schemas during the transition. Feature flags are one way to route traffic that depends on the new column until the backfill finishes.