Adding a new column should be fast, explicit, and safe. The schema must keep its integrity. The query planner must stay efficient. You cannot afford ambiguous types or default values that break production.
A new column in SQL starts with ALTER TABLE. But in a live system, the naive approach can lock rows and freeze writes. On high-traffic databases, blocking operations can cascade into outages. Always measure the impact before running the migration.
Plan the column. Define its name, type, nullability, and default. If you add a NOT NULL column without a default, the migration will fail unless every row has a value. When using PostgreSQL, ADD COLUMN ... DEFAULT can rewrite the entire table unless you use a constant and then update in batches. MySQL and MariaDB use similar rules but can apply defaults without a full table rewrite in some cases.
Test in staging with production-scale data. Benchmark insert, update, and select queries before and after the change. Check your ORM migrations for hidden schema assumptions. Some tools generate commands that run well on small datasets but degrade under load.