Adding a new column sounds trivial. It rarely is. Whether you use PostgreSQL, MySQL, or a distributed datastore, schema evolution can break deployments, block writes, or lock entire tables. Production databases hold billions of rows. An unplanned ALTER TABLE ADD COLUMN can cause downtime you cannot afford.
Plan the new column with precision. Start by defining its exact type, constraints, and nullability. Decide on a default value only if you need one. In PostgreSQL, adding a column without a default is fast because it updates metadata, not data. Adding a default forces a full table rewrite. In MySQL, column order can still matter for storage layout and replication.
Handle backfills carefully. For large datasets, run a staged rollout:
- Add the new column as nullable.
- Deploy code that writes to both old and new fields.
- Backfill in small batches with throttling.
- Switch reads to the new column.
- Remove legacy fields when safe.
Use tools that support zero-downtime schema changes. For MySQL, gh-ost or pt-online-schema-change can run the migration without blocking writes. For PostgreSQL, logical replication or background workers can stream updates while you backfill. Test on a realistic dataset before touching production.