Adding a new column sounds simple. In practice, it can break queries, trigger locks, and stall deployments. A schema change in a live system must be fast, safe, and reversible. Whether in PostgreSQL, MySQL, or any other relational database, a badly executed ALTER TABLE can grind a service to a halt.
A new column is not just about adding fields. It is about managing data integrity, ensuring indexes align, and keeping replicas in sync. In PostgreSQL, using ALTER TABLE ADD COLUMN is straightforward if the column is nullable and has no default. The command runs instantly because it only updates metadata. But the moment you set a non-null default, the change rewrites the entire table. That rewrite locks writes, increases I/O load, and can cause downtime.
In MySQL, similar rules apply. Adding a nullable column is cheap. Adding a NOT NULL column requires a table copy unless you use an online DDL operation. Even with ALGORITHM=INPLACE, not all storage engines support it. Testing in staging is crucial before applying changes to production.
For production systems, break the process into safe steps: