Changing a database in production is never trivial. A new column can break queries, slow indexes, or lock critical tables. The key is to plan and execute without disrupting uptime. The steps are simple, but the constraints are not.
First, define the purpose of the new column. Confirm its data type, default value, and how it interacts with existing indexes. Avoid unnecessary writes during the migration. For example, set a nullable column first, then backfill in controlled batches.
Second, update your schema using safe migration patterns. In PostgreSQL, ALTER TABLE ADD COLUMN is fast for most types, but a default with a non-null constraint can lock the table. Split the migration: add the column as nullable, then add constraints after the data exists. In MySQL, watch for table rebuilds depending on the storage engine and column type.
Third, deploy application code in sync with the migration. Gate writes to the new column until the schema is in place. Handle reads defensively to avoid breaking downstream services. Feature flags make this safer.