Adding a new column sounds simple. It is not. Every schema change touches the core of your data model. It can break queries, cascade through services, or block deploys if not planned. The first step is deciding the column name and data type. Keep it consistent with existing conventions. Avoid implicit type conversions that cause full-table writes.
In relational databases like PostgreSQL and MySQL, adding a nullable column with no default is fast—instant on large tables. But adding a column with a default value can rewrite the entire table, locking writes for seconds or hours depending on size. In production, that risk is unacceptable. Use NULL defaults, backfill asynchronously, then apply constraints in a safe migration step.
For high-traffic systems, online schema change tools like pt-online-schema-change or gh-ost reduce downtime. They create a shadow table with the new column, sync changes via triggers, and swap tables atomically. This lets you add a new column without blocking operations.
In distributed systems, version your database changes alongside your application code. Ship migrations ahead of the app code that uses them. This enables backward compatibility during rolling deploys. Do not drop or modify the new column until every dependent service is updated.