The migration ran clean until the last step. Then the error hit: missing column.
Adding a new column should be simple, but small mistakes here cause downtime and lost data. The safest path is to plan the schema change, apply it with minimal locking, and keep it reversible. A new column in a relational database changes both the schema definition and the application code that depends on it. The wrong sequence can break queries or confuse background processes.
When adding a new column in SQL, define the exact data type, default value, and constraints. Avoid adding non-nullable columns without defaults unless the table is small and the write lock is acceptable. For large tables, apply the new column with a nullable state first, backfill data in batches, and then alter it to non-nullable. This keeps reads and writes flowing while the schema evolves.
In PostgreSQL, ALTER TABLE table_name ADD COLUMN column_name data_type; is the minimal form. In MySQL, the equivalent operation is also straightforward, but engine-specific locking behaviors can disrupt live traffic. In both systems, tools like pg_online_schema_change or gh-ost help run migrations without blocking writes.