A new column in a database table sounds simple. It can be. It can also be a costly trap if you fail to plan the change. In production, adding columns affects storage, query performance, index design, and possible table locks. For large datasets, a single ALTER TABLE can block reads or writes for minutes—or hours—depending on the database engine.
The first step is knowing the type of column you need: nullable, non-null with default, generated, or virtual. Each type triggers different behaviors during the migration. In PostgreSQL, adding a nullable column without a default is nearly instant. MySQL behaves differently: even nullable columns may copy table data depending on the engine and version.
If you must set a default value for a new column, consider backfilling in batches to avoid downtime. Use feature flags at the application level so the code can tolerate the column being absent during rollout. This prevents deploy failures when schema changes propagate at different times across environments.