That single line in a migration script can block a release, block a team, block revenue. A new column in a database table looks simple. It is not. It touches schema design, indexing strategy, data integrity, and deploy safety.
Before adding a new column, decide its type and constraints. Choose the smallest data type that holds the required values. Smaller types reduce storage and improve query performance. Set NOT NULL only if you can guarantee every row will have a value. If you need a default, define it in the schema to avoid null checks in your code.
Index only if the column will be used in lookups or joins. Every index adds write overhead. Use partial indexes when only a subset of rows is queried. Review how the new column fits into existing composite indexes. Avoid creating redundancy that impacts insert speed and storage.
Plan the migration. In large datasets, adding a new column with a default value can lock the table. Break changes into safe steps: add the new column without defaults, backfill in batches, then add constraints. Use transactional DDL only when the engine supports it without long locks.