A single schema change can decide the fate of your release. You need a new column. You need it fast, without downtime, without breaking the API, and without corrupting production data.
Adding a new column in a database is simple in theory. In practice, it can cripple performance if handled carelessly. The process depends on your database engine, migration strategy, and usage patterns. PostgreSQL, MySQL, and other relational systems have different rules for altering tables, locking writes, and backfilling data. Understanding these differences is not optional.
In PostgreSQL, adding a new nullable column is usually instantaneous because it updates metadata without touching each row. But making it NOT NULL with a default forces a full table rewrite—often blocking reads and writes for minutes or hours on large datasets. The correct move is a two-step migration: first add the column as nullable, then backfill in batches, then enforce constraints.
In MySQL, ALTER TABLE can lock the whole table unless you use ALGORITHM=INPLACE or table partitioning where supported. On high-traffic replicas, run schema changes online or during maintenance windows. With cloud-managed databases, watch for hidden replication delays after the DDL operation.