Adding a new column to a production database is simple in theory and dangerous in practice. The wrong migration can lock tables, slow queries, or trigger outages. Yet new columns are inevitable. Requirements change, products grow, and storing more data becomes necessary.
Plan the change before you type a single ALTER TABLE. Start with the column name and data type. Choose names that are short, precise, and consistent. Select types that match the smallest size needed for the data. Keep indexes in mind. Adding an index when you create the column can save time later, but it can also extend migration runtime.
In relational databases like PostgreSQL or MySQL, adding a column without a default value is usually instant. Adding one with a default often rewrites the entire table. On large datasets, that means downtime unless you use a safer pattern—add the column as nullable, backfill in batches, then set the default and constraints.
Test the migration on a staging environment with production-sized data. Measure the runtime and query performance before and after. Watch for side effects in ORMs or application code. Many frameworks assume the table schema is fixed at deploy time; a missing migration step can break production.