The database was silent until the schema shifted. A new column appeared, carving out fresh space for data and changing the rules of every query that touched it.
Adding a new column is not cosmetic. It alters storage, indexing, and memory usage. It can affect read performance, write performance, and replication lag. In production systems, even a small schema migration can cascade into downtime or slow queries if handled without care.
The first decision is column type. Choose the smallest data type that fits the domain. Smaller types reduce disk space, increase cache efficiency, and keep indexes lean. Define NOT NULL constraints only when the data guarantees it; otherwise, the migration may fail on existing rows.
Next, decide on the default value. In many systems, adding a column with a non-null default rewrites the entire table. That’s a blocking operation in MySQL and can lock writes for minutes or hours. Avoid table rewrites by adding the column without a default, then populating it in batches. PostgreSQL 11+ can add a column with a constant default instantly if no rewrite is required, but confirm behavior in your specific version before deploying.