A database without evolution is a dead system. At some point, the schema must grow, and the fastest way to expand is to add a new column.
Adding a new column sounds simple, but in production it is a live change to a moving target. You have active reads and writes. You have indexes to consider. A careless ALTER TABLE can lock rows, spike latency, or even bring the service down.
The first step is choosing the right migration strategy. Online schema changes reduce downtime by applying the new column while the database remains responsive. Tools like gh-ost or pt-online-schema-change handle this in MySQL; for PostgreSQL, ALTER TABLE ADD COLUMN is often safe if the column is nullable or has a default that doesn’t require rewriting all rows.
Think about data types before you commit. A new column with the wrong type can force costly transformations later. Keep columns lean—avoid oversized text if the field stores IDs or short codes.
Consider defaults carefully. Adding a default with a constant value can trigger a full table rewrite depending on your database version. If you need a default, sometimes setting it in application code first avoids performance pain, then later applying it at the schema level.