Adding a new column is one of the most common schema changes in any database. It sounds simple. It rarely is. A small change in schema can trigger migrations, downtime, lost records, or degraded query performance. In production, a misstep can cost more than code bugs.
The process begins with clarity. Define why the new column exists and the type it needs. Use explicit types. Avoid nullable columns unless they are truly optional. Nulls propagate complexity through queries and APIs.
In relational databases, adding a new column at scale means knowing your engine. PostgreSQL can add columns with default null values almost instantly, but adding a non-null column with a default value rewrites the table. That rewrite can lock writes for minutes or hours on large datasets. MySQL and MariaDB perform similar operations but with different locking behaviors. Planning is critical.
For schema migrations in production, run the change on a replica first. Measure the impact on queries and indexes. If the new column requires an index, consider whether to build it concurrently to avoid blocking. Always test load and rollback paths.