Adding a new column should be instant, safe, and clear. In reality, it is a decision that affects data integrity, query performance, and code stability. Bad migrations create outages. Good migrations vanish into the background and scale for years.
A new column in a production database is more than just ALTER TABLE. You choose the name, type, and constraints with intent. You match nullability to real data patterns. You define defaults only if they match all use cases. You know whether to backfill or to start empty. You avoid locking tables when traffic peaks.
Plan every step. Decide if you can add the new column online. For large tables, use migration tools that chunk writes and avoid blocking reads. For small tables, a single transaction may be fine.
Deploy the migration before you write the application code that uses it. This avoids errors when fields are missing. Roll out reads first, then writes. Only after the column is stable in production should you enforce constraints or indexes.