A single line of code can decide the shape of a database. Adding a new column is one of the most common schema changes, but it can also be one of the most disruptive if done without care. Speed and safety live in tension here. Get it wrong, and you risk downtime or corrupted data. Get it right, and your system moves forward without a hitch.
When you add a new column to a live database, you change not only the schema but also the expectations of the application and every service that touches it. Migrations must be designed to work with live traffic. On production, that means avoiding locks on critical tables and ensuring backward compatibility until the deployment completes.
In PostgreSQL, adding a column without a default value is fast, because it only changes the metadata. Adding a column with a default and a NOT NULL constraint will rewrite the entire table, which can freeze queries. The same pattern applies across databases: the fastest path is to add the column as nullable, backfill the data in small batches, then apply constraints in a later migration.
In MySQL, beware of storage engine differences. InnoDB will copy the table for most ALTER TABLE operations. For large datasets, this can block reads and writes for minutes or hours. Use ALGORITHM=INPLACE or online schema change tools such as pt-online-schema-change to avoid downtime.