Adding a new column sounds simple, but in production systems it can be dangerous. Schema changes can lock tables, block reads, and break downstream services. The right approach depends on scale, latency budgets, and the database you run in production.
In PostgreSQL, ALTER TABLE ... ADD COLUMN is metadata-only if the column has no default value. This is fast and safe. If you define a default, Postgres rewrites the table on older versions. That can take hours for large datasets. MySQL behaves differently: adding a column may copy the table, unless you are on newer versions with instant DDL.
Before adding a new column, confirm the migration path. Test in a staging environment with production-like load. Monitor query plans, replication lag, and application-level errors. In distributed systems, deploy schema changes in phases. Add the column first with null values, then backfill data asynchronously, then enforce constraints if needed.
Use feature flags to control access to the new column from application code. This lets you roll out without exposing partial data or creating version drift between writes and reads. Always keep migrations idempotent and reversible.