Adding a new column to a database table is a simple act with deep consequences. Schema changes affect performance, integrity, and deployment speed. The wrong move can lock tables, block writes, and stall production. The right move can expand capability without downtime.
The basics are clear: define the column name, data type, nullability, and default value. But in production databases, the details matter. ALTER TABLE commands can trigger table rewrites depending on the engine. Large datasets turn trivial operations into heavy I/O. Adding a NOT NULL column without a default can break inserts. Migrating with zero downtime often requires staging, backfilling, and careful sequencing.
For relational databases like PostgreSQL and MySQL, adding a column with a default value may rewrite the entire table. This increases lock time and replication lag. Many teams work around this by first adding the column as nullable, then backfilling in small batches, and finally setting constraints. In distributed systems, schema evolution must also maintain compatibility across services and versions.