The simplest answer was a new column. But adding it wrong could freeze production, corrupt data, or trigger an irreversible migration disaster.
A new column is more than an extra field. It changes the shape of your data. It shifts indexes, queries, and even application logic. Designed well, it extends your schema with precision. Designed poorly, it becomes technical debt from the start.
When adding a new column, define its purpose explicitly. Resist adding “just in case” fields. Every column increases storage, affects row size, and can slow writes. Align the new column with actual read and write patterns. Consider future data types and constraints early — nullability, default values, and unique keys.
Plan migrations. Backfill if needed, but avoid locking large tables during peak traffic. For massive datasets, use online schema change tools. Deploy in phases. Add the column first, then roll out code that uses it, so you can revert if needed without losing uptime.