Adding a new column is simple in theory: write the migration, update the application logic, deploy. In practice, each step can break production if handled without care. The database engine will lock rows. Queries will slow. Old scripts will choke on nulls.
Start with the schema migration. Always define the new column with a clear data type and constraints. Avoid nullable unless it is truly optional. Name it so the meaning is obvious. This prevents misreads months later when your team is gone and the logs are your only clue.
Run the migration in a controlled window. For large tables, consider online schema changes to keep downtime near zero. Tools like pt-online-schema-change or native database features can help. Test them against a copy of production data before you touch the real thing.
Update the application code as soon as the database can accept the new column. This means adding it to your models, including it in API responses when needed, and wiring it through serializers or DTOs. Keep backward compatibility until all consumers are updated.