Adding a new column is simple, but doing it right avoids corruption, downtime, and regressions. In SQL, a column change can block writes, trigger long locks, or break API contracts. The right approach depends on your database engine, schema size, and deployment strategy.
In PostgreSQL, ALTER TABLE ADD COLUMN runs fast for nullable columns with defaults set to null. But adding a default value on creation rewrites the table. For MySQL, ALTER TABLE often copies the full table, making it slow for large datasets unless you use tools like pt-online-schema-change or native online DDL.
When adding a new column in production, first confirm that all application code can handle both old and new schemas. Deploy code that reads the column without expecting it to exist. Then add the column in a backward-compatible migration. Only after verifying writes should you enforce constraints or defaults that change storage.
Index changes alongside a new column can be dangerous. Always add indexes in separate migrations to reduce risk. Monitor replication lag if you run replicas; schema changes can slow or block replication.