The query ran. The table stared back, complete but missing the one thing you need: a new column.
Adding a new column should be fast, safe, and clear. Yet in production systems, schema changes can stall deploys, lock rows, or cause downtime. Whether you work in PostgreSQL, MySQL, or a modern cloud database, the goal is the same—alter the schema without breaking the application or the data pipeline.
A ALTER TABLE ... ADD COLUMN command is the simplest step. But simplicity vanishes under load. Before adding a new column, define its nullability, default values, and data type. Avoid defaults that trigger full table rewrites on large datasets. If you must backfill, batch it—never run a single massive update. Use NULL defaults and migrate the values incrementally.
In PostgreSQL, adding a nullable column without a default is instant, no matter the size. The problem begins when you add a default to existing rows. Plan for that in a separate migration. MySQL behaves differently; it can hold metadata locks, impacting reads and writes. Always test the migration in a staging environment with production-like data volumes.