Adding a new column sounds simple. In practice, it can collapse a release if not planned. Schema changes alter the contract between application code and the database. Every new column carries risk: null handling, default values, indexes, foreign keys, and performance impacts on large tables.
Before adding the column, define its type with precision. Use exact data types, not generic ones. Establish whether it accepts nulls or must default to a value. For high-throughput tables, calculate the lock time for the column addition. In MySQL, certain operations are online, but others require a full table rewrite. In PostgreSQL, adding a new column with a constant default can still rewrite the table unless you use an expression that avoids a backfill.
Study the deployment strategy. For zero-downtime deploys, add the new column in one migration, then backfill in batches to avoid locking. Deploy code in stages: first write to both old and new columns, then read from the new one once data is complete. Use feature flags to switch reads once verified.