Adding a new column to a production database is a high‑impact operation. Do it wrong, and you risk blocking queries, ballooning replication lag, and breaking application code. Do it right, and it’s another invisible change that ships without incident.
Plan the migration. First, decide the column type, nullability, default value, and indexing strategy. Avoid adding indexes in the same operation unless the table is small; large indexes can lock writes for minutes or hours.
Use a safe migration pattern. For Postgres and MySQL, adding a nullable column without a default is usually constant time. For defaults, write them in application code, backfill asynchronously, and then add constraints once data is complete. In high‑traffic systems, use tools like pt-online-schema-change or gh-ost for non-blocking alters.
Coordinate with application changes. Deploy code that can handle the absence of the new column first. Then, after the column exists, enable writes to it. This two-step rollout avoids race conditions and deserialization errors.