Adding a new column is one of the most common schema changes, yet it’s also one of the most destructive if done without care. A poorly planned migration can lock tables, stall writes, and cause downtime. The right process makes it safe, fast, and repeatable.
First, define the new column in your migration script with explicit types and default values. Avoid null defaults unless truly necessary; they complicate downstream logic and indexing. If your dataset is large, use an online schema change tool to avoid long‑running locks. In PostgreSQL, ALTER TABLE ... ADD COLUMN is transactional, but adding defaults to large tables can still block. For MySQL, tools like gh-ost or pt-online-schema-change limit impact.
Second, roll out code that writes to the new column before code that reads from it. This ensures fresh data is present when reading starts. Use feature flags to toggle usage on or off without redeploying. Keep writes dual‑pathed to old and new columns during the transition if you need to backfill.