The database schema had to change, and it had to change fast. A new column was the only way forward. No workarounds. No deprecated fields. No brittle hacks left from old migrations.
Adding a new column sounds simple, but production databases make it a high-stakes operation. You face locked tables, stalled queries, and downtime windows that cost real money. The wrong migration strategy can turn a release into a rollback.
A clean ALTER TABLE ... ADD COLUMN works for small datasets. For large tables, you need an online schema change. Tools like pt-online-schema-change or native online DDL keep your table available while the new column builds in the background. Test these changes against a staging environment that mirrors production scale before touching live data.
Define the column with the correct data type and constraints from the start. Changing a column later is harder than adding one cleanly. If the new column requires a default value, watch for full table rewrites that can spike I/O. Opt for a nullable column first, then backfill data in controlled batches.