The table was live in production when the request came in: add a new column. No downtime. No risk. No rollback. Just do it.
Adding a new column sounds simple. In reality, it can break queries, slow writes, and lock up transactions if done wrong. A careless migration can cascade into failures across services. The way to add a new column safely depends on the database, the volume of data, and schema migration strategy.
In PostgreSQL, adding a nullable column without a default is usually instant. Declare it with ALTER TABLE ... ADD COLUMN, and no data rewrite occurs. But set a default on millions of rows and you risk a full table rewrite, triggering long locks. In MySQL, even seemingly small schema changes can trigger table copies, depending on the storage engine and version. Avoid this by using ONLINE or INPLACE algorithms where supported.
Backward compatibility is non‑negotiable. Deploy the schema change first, let it propagate, then deploy the code that writes to the new column. Only after the new writes stabilize should reads depend on it. This staged rollout prevents null errors and keeps both old and new code running side‑by‑side without conflict.