The table was built and running in production when you realized it needed a new column.
Adding a new column should be simple. In practice, it can break queries, block deployments, and trigger long table locks. Schema migrations in live systems demand care. The right approach depends on database type, table size, and uptime requirements.
In PostgreSQL, adding a new column with a default value rewrites the entire table. On large datasets, this can hang writes for minutes or hours. The safe option is to add the column as NULL first, then backfill in small batches. In MySQL, an ALTER TABLE may trigger a complete table copy unless you use ALGORITHM=INPLACE where possible. With NoSQL systems, adding fields is often schema-less, but application code must still handle unset values cleanly.
A new column also affects indexing and performance. If you need the column indexed, create the index after the data load, not before. This avoids repeated index updates during the backfill. Plan for how the new field interacts with existing queries. Check if ORMs or query builders will start including it by default. Understand execution plans before and after the change.