The table was fast, but the data model changed. You need a new column, and you need it without breaking production.
Adding a new column to a database table looks simple, but the details decide whether your deployment runs clean or causes downtime. A new column affects schema, queries, indexes, and migrations. It also impacts every part of your application that reads or writes to that table.
Start by defining the column name, type, and constraints. Make your choice explicit—text, integer, boolean, timestamp. Decide if it allows NULLs. Decide if it needs a default value. For large tables, adding a column with a default at the database level can lock writes. In high-load production, add the column without the default, then backfill in batches, then set the default in a follow-up migration.
Test your migration on a staging database with production-scale data. Measure execution time. Check locks. Profile queries that touch this table. Updating code and schema together demands feature flags or a two-step deploy: first add the column, then roll out code that reads or writes to it.