Adding a new column to a production database is not just another migration. It changes the shape of your data. Every row gets a new field. Every query touching that table may feel the impact. If you do it wrong, you risk downtime, data corruption, or subtle bugs that surface months later.
The safest path starts with a migration script built to run without locking the table for too long. Use ALTER TABLE with care. Add the column as nullable first, even if it will be NOT NULL later. This avoids blocking writes and reads while the change applies. For very large tables, consider adding the column in steps: create it, backfill data in small batches, then add constraints.
Default values can be dangerous at scale. A default on a new column can cause the database to rewrite every row immediately. Instead, set defaults in application logic, let the backfill populate values, and add the default and constraints later.
Every index you add on a new column slows down inserts and updates. Do not create indexes until you have production queries that require them. Test queries against replicas to see if indexing is worth the write penalty.