The query ran. The table was huge. You needed a new column, and every second mattered.
Adding a new column sounds simple. In reality, it can be the difference between downtime and seamless deployment. Schema changes in relational databases are easy to type but hard to execute without risk. Operations that lock the table can stall writes. Long-running migrations can block reads. In distributed systems, adding a column without a plan can create silent data corruption.
The first step is knowing the source database. Postgres, MySQL, and SQLite each handle ALTER TABLE ADD COLUMN differently. Postgres can often add a nullable column instantly, but adding one with a default can rewrite the whole table. MySQL supports fast column additions in certain engines, but performance depends on row format. SQLite requires a careful sequence when altering schema, especially with constraints.
Next, decide on column properties. Nullable avoids immediate rewrites. Non-null requires defaults or a two-step migration. Use NULL first, then backfill in batches, and finally enforce constraints. This pattern prevents locks from taking your service offline. For big tables, run backfills with controlled concurrency to avoid I/O spikes.