You knew the schema was wrong, and the fix was obvious: a new column.
Adding a new column should be the simplest kind of schema migration. Yet in production, even a small change can break queries, stall writes, or lock a table long enough to cause downtime. The stakes are higher when datasets are huge or when systems serve traffic around the clock.
A new column can hold fresh data, reduce complexity in application logic, or enable new product features. But doing it well means controlling for both performance and safety. Before you run ALTER TABLE, you need to consider type, nullability, indexing, defaults, and impact on replication. A careless choice can cascade through every dependent system.
For large tables, online schema change tools such as gh-ost or pt-online-schema-change can help by creating a shadow table, copying data incrementally, and swapping once complete. Modern cloud databases sometimes offer instant metadata-only operations for certain types of columns, but only if constraints are minimal. In transactional systems, you must measure lock time, test rollback paths, and be ready for partial failures.