The query returned in seconds, but the data was wrong. A missing field broke the response. The fix was a new column.
Adding a new column in a database is simple in theory and dangerous in practice. Schema changes can lock tables, block writes, and cascade into downtime. In production systems, even a single ALTER TABLE can cause delays that users notice. The key is to add new columns with zero disruption.
First, understand how your database engine handles schema migrations. PostgreSQL and MySQL differ. PostgreSQL often adds new columns instantly if they have no default or are nullable. MySQL’s behavior depends on storage engines and versions. Always test the migration in a staging environment with production-like data sizes. Measure the time and resource usage before repeating it in production.
Second, choose safe defaults. If a column can be null, add it without a default value to speed the operation. If you need a default, set it in the application layer after deployment instead of during the migration. This avoids rewriting every row immediately, reducing lock contention.