Creating a new column should not feel like open-heart surgery. Yet too often, adding a column to a database means downtime, risky migrations, or tooling that hides too much behind opaque commands. In systems where performance and correctness matter, you have to think through every step. The choice between ALTER TABLE and creating a new table with a copied schema is not trivial. Each path has tradeoffs.
A new column requires clarity on type, nullability, and default value. Without these decisions locked in, you risk inconsistent state or index fragmentation. Adding a nullable column with no default is cheap, but retrieval costs grow when every query has to handle cases where the column has no value. Adding a non-null column with a default is safer, but can trigger a full table rewrite depending on the database engine.
In PostgreSQL, ALTER TABLE ADD COLUMN is fast for nullable fields without defaults. For MySQL, adding a column to large tables can lock writes unless you use tools like pt-online-schema-change or native online DDL features. In distributed databases, a schema change triggers metadata updates across nodes, and propagation delays can cause temporary mismatches. Plan accordingly.