Adding a new column should be simple. In practice, it is one of the most common sources of blocked deploys, table locks, and performance regressions. The details matter. Choosing data types, setting defaults, and deciding on nullability all shape how the database will store and index the new field. A careless ALTER TABLE can scan millions of rows and lock writes for minutes or more.
The safest way to add a new column depends on the database system. In PostgreSQL, adding a nullable column without a default is instantaneous. Adding a column with a default rewrites the table unless you set the default after creation. In MySQL, new columns often require a table copy unless you use ALGORITHM=INPLACE or INSTANT. SQLite rewrites the table for almost any schema change. Knowing these behaviors lets you plan migrations that complete in seconds instead of hours.
Version control for schema changes is essential. Use migration files that can run forward and backward. Test them on production-like datasets. Monitor query performance when the new column goes live. If you plan to backfill data, run it in small batches to avoid saturating I/O and locking rows needed by users.