It alters the shape of your data, the queries you write, and the way you ship features. One line in a migration can ripple through every service that reads or writes that table. Done well, it tightens your schema. Done poorly, it breaks production.
When you add a new column, you are expanding your model. Before touching the migration tool, decide the column name, type, constraints, defaults, and indexing. Precision here prevents expensive rewrites later. If the column must be nullable, know why. If it must be unique, enforce it in the schema, not just in the application.
Think about the impact on existing queries. SELECT * will start returning more data than before. ORM models will shift. Downstream consumers may break if they expect a fixed shape. Plan the deployment. Migrate with backwards compatibility. Add the column first, populate it asynchronously if needed, then switch code paths.
For large tables, adding a new column can lock writes and cause downtime depending on the database engine. Use online schema change tools for MySQL or chunked ALTER TABLE strategies for PostgreSQL. Test the migration in staging with production-sized data. Measure both migration time and runtime query performance after the change.