The table was breaking. Queries that once ran in milliseconds now dragged like they're stuck in mud. You knew the cause before the profiler told you: you need a new column.
Adding a new column is not just an insert into the schema. It’s a decision with weight. In production, every schema change carries risk. Blocking database operations can lock tables, drop cache efficiency, and impact uptime. A ALTER TABLE ... ADD COLUMN seems simple in theory, but the implementation matters.
First, define the exact data type. A new column must align with existing indexing and query patterns, or you risk bloating storage and creating slow scans. If you plan to join on the new column, index strategies and null handling must be in place before deployment.
Second, assess the migration strategy. For small datasets, you can run the schema change inline. For large, high-traffic databases, use an online schema change tool like pt-online-schema-change or gh-ost. This lets you add a new column without long locks, keeping your service live.