Adding a new column to a database is simple in syntax but complex in impact. Done right, it unlocks features. Done wrong, it slows performance, triggers downtime, and increases operational risk. In high-volume systems, a schema change is never just a schema change.
Plan the new column before you write the ALTER TABLE command. Define its purpose, data type, default value, nullability, and indexing requirements. Avoid adding columns without analyzing query patterns and storage costs. A small decision in schema design can scale into terabytes of waste.
In most relational databases, ALTER TABLE <table> ADD COLUMN <name> <type>; is the basic form. That command may lock the table until the change completes. On a large dataset, this can block inserts and updates. In PostgreSQL, adding a nullable column without a default is fast because it updates only the schema metadata. Adding a column with a default value rewrites every row and can be slow.
For MySQL and MariaDB, newer versions support ALGORITHM=INPLACE or ALGORITHM=INSTANT to avoid a full table copy. Use these when possible. In distributed databases, the change might propagate asynchronously, so test on a staging cluster before deploying to production.