The migration was complete. Tables rebuilt, indexes tuned. But the query still failed because one field was missing: the new column.
Adding a new column seems trivial. In practice, it can break production if handled without care. Schema changes in live systems require speed, safety, and minimal downtime. A single misstep can cascade into locked queries, stale replicas, or corrupted data.
When adding a new column in SQL—whether in PostgreSQL, MySQL, or SQLite—the process must factor in storage allocation, lock behavior, and replication lag. In PostgreSQL, ALTER TABLE ADD COLUMN is fast if no default value is set; with a default, a full table rewrite may occur. In MySQL, large tables with ALTER TABLE can block writes unless using ALGORITHM=INPLACE or an online DDL tool. SQLite requires a simple ALTER TABLE ... ADD COLUMN, but removing mistakes means rebuilding the table.
Plan for backfills. If a new column needs historical data, write migration scripts that chunk updates to avoid write storms. Use feature flags to toggle new-column reads until the data is ready. Test on staging with a full dataset and production-like load before touching live servers.