A new column is simple in theory. In reality, it can fracture performance, lock tables, and choke requests under load. Schema changes affect indexes, queries, replication, and backups. Doing it right means understanding the exact behavior of your database engine and how to stage the migration with zero disruption.
For relational databases, adding a new column with a default value can lock writes if the system has to rewrite each row. In PostgreSQL, adding a nullable column without a default is instantaneous, but adding with a non-null default can be costly unless you follow a pattern that defers row updates until needed. In MySQL, the impact depends on storage engine and version—modern releases support instant column addition for many operations, but not all.
Application logic must be ready before the schema changes hit production. That means designing migrations that are backward- and forward-compatible, deploying code that can handle both the old and new schema, and only then running the ALTER TABLE command in production. Background migrations can populate data in the new column without locking hot tables.