Adding a new column sounds simple, but the wrong approach can lock writes, slow reads, and break upstream services. Schema changes touch every part of the system. Get them wrong, and you face downtime, inconsistent data, or expensive rollbacks. Get them right, and you evolve your database without users noticing.
Start by deciding if the new column is nullable or has a default value. Non-null columns on large tables can cause a full table rewrite. Plan the migration to avoid blocking operations. In PostgreSQL, adding a nullable column with no default is fast. Adding one with a constant default is also efficient from version 11 onward. For MySQL, expect a lock unless you use tools like pt-online-schema-change or gh-ost.
Avoid adding unused columns “just in case.” Each one increases storage, index size, and query complexity. If the column is critical, add it in stages: first add it as nullable, then backfill in small batches, then enforce constraints. This reduces replication lag and minimizes risk in production.