The migration script was already live when someone realized the schema needed a new column. No time for debates. No time for perfect diagrams. The database had to change now.
Adding a new column sounds simple. In practice, it can break queries, slow writes, and trigger costly downtime if handled without care. The actual process and impact depend on the database engine, the size of the table, the indexing strategy, and the queries hitting it in production.
In relational databases like PostgreSQL or MySQL, a new column can be added with an ALTER TABLE statement. This is atomic on small tables but can lock large ones for seconds or minutes. For columns with default values, some engines will rewrite the entire table, which can crash availability. Always test the operation on a copy of production data. Measure the timing of the DDL, check for locks, and validate your rollback plan.
In distributed systems or NoSQL environments, adding a new column often means updating the data model or schema definition in code. Column additions may require rolling out new application versions that can handle both the old and new schema until migration is complete. Use feature flags for any query paths that read or write the new field.