The table was fast, but it needed more. You needed a new column. Not a thought experiment—an actual column in production, holding data before the next deploy window closed.
A new column changes your schema. It touches queries, indexes, and migrations. It changes how data flows through your application. Get it wrong, and the system breaks. Get it right, and your database evolves without downtime or data loss.
First, decide the column type. Match it to your workload: integer for IDs, text for names, JSON for flexible structures, timestamp for event ordering. Avoid overgeneralizing. A poorly chosen type locks you into bad constraints for years.
Second, handle nulls and defaults. Adding a non-null column to a large table will lock writes unless you set a default value. If your database supports fast metadata changes, use that. If not, run a backfill in small batches to avoid blocking queries.
Third, modify indexes only after you’ve added the column. Adding an index at the same time as the column can create long locks. In busy systems, create the column, verify it’s live, then build the index in a separate transaction.