Adding a new column to a database table sounds simple. It can be. But it can also destroy performance, lock critical writes, and push a migration over the edge if not handled with care. The difference is in the approach.
First, every new column must have a clear purpose. Define its data type, constraints, and default values before you touch production. Avoid arbitrary defaults unless they match a real use case. A poorly planned default on a large table can force a full table rewrite.
Second, understand lock behavior. In PostgreSQL, adding a nullable column without a default is fast and avoids table rewrites. In MySQL, some column changes can still trigger full-table locks depending on storage engine and configuration. Read your database’s migration documentation, not just a blog post summary.
Third, if the new column is part of a live, high-traffic service, use additive, backward-compatible changes. Add the column as nullable. Backfill data in small batches. Deploy application logic that can handle both old and new schemas during the transition. Only after the data is fully populated should you enforce constraints.