The migration finished at 3:17 a.m., but the new column wasn’t in the table.
Adding a new column should be simple. In practice, it can break queries, slow deploys, and lock rows at the wrong moment. Whether you use PostgreSQL, MySQL, or any modern relational database, the process demands precision. Schema changes in production leave no margin for error.
A new column changes the shape of your data. That change must flow through migrations, deployments, and code in sync. The database needs to store it. The application needs to write to it. Reads must be safe before and after it exists. If any step runs out of order, you risk outages or corrupt rows.
In PostgreSQL, ALTER TABLE ... ADD COLUMN is fast for nullable fields with defaults set at the application layer. Adding a non-null column with a default at the database level rewrites the entire table. On large datasets, that can lock writes for minutes or longer. In MySQL, adding a column to an InnoDB table may require a table copy, depending on version and storage format. Always test schema changes in a staging environment with production-scale data.