A database change can be small in code yet massive in impact. Adding a new column changes storage, queries, indexes, and application logic. Done right, it unlocks new capabilities. Done wrong, it triggers downtime, errors, and late-night rollback scripts.
When you add a new column in PostgreSQL, MySQL, or any other relational database, the first question is: does it need a default value? In many engines, adding a NOT NULL column with a default will rewrite the entire table. On large datasets, this means blocking operations and degraded performance. Better to add the column as nullable, backfill in batches, then enforce constraints.
Plan migrations. Use transactional DDL where possible. Wrap schema changes in tested scripts. Review query plans before and after. A new column can break cached statements, invalidate ORM mappings, or cause implicit casts that harm performance.
In distributed systems, a schema change must be backwards-compatible until all services are updated. Deploy code that reads the new column before code that writes it. Only after adoption should you enforce stricter rules or remove fallback logic.