Adding a new column in a database migration should be deliberate. It is not just another field. It is an agreement: the data will exist, the code will know it, and the platform will respect it. In PostgreSQL, ALTER TABLE ... ADD COLUMN makes it real. In MySQL, the syntax is almost as short. But in production, speed and safety matter more than syntax.
A new column can trigger a full table rewrite, locking writes and blocking updates if done the wrong way. Big tables demand strategies that avoid outages. Add the column as nullable. Give it a default later with a backfill that runs in small batches. Verify indexes only when they are needed. Avoid cascading schema changes through dependent services without testing.
Work with migrations that can be rolled forward. Use feature flags to mask the new field until it is safe to expose. Run schema diffs in staging to confirm nothing breaks. Watch query plans before and after the change; a single new column can change the optimizer’s choices.