A new column sounds simple. In practice, the wrong migration can lock rows, stall queries, and trigger a full table rewrite. The right approach depends on database type, size, and traffic pattern. In PostgreSQL, adding a nullable column with a default can cause a total table rewrite unless you separate the steps: first add the column without default, then update it in batches. In MySQL, ALTER TABLE can block writes unless you use ONLINE DDL or tools like gh-ost or pt-online-schema-change.
When designing schema changes, plan for lock behavior, replication lag, and index rebuilds. Document every change. For large datasets, roll out the schema update in small, reversible steps. Test in staging with real-world queries and load. Use feature flags or conditional application code to handle rows both with and without the new column until the rollout is complete.
A new column is rarely just a column. It is a migration, a deployment, and a contract change all at once. Treat it like code: version it, review it, and measure its impact. Automate where possible. In CI/CD pipelines, run migrations early in deploy cycles so failures are caught before peak traffic.