The query returned, but the data felt wrong. The table structure had changed. You needed a new column, and you needed it without breaking the rest of the system.
Adding a new column seems simple—until it isn’t. In production environments, schema changes can stall deployments, lock tables, or cause downtime. The right approach depends on the database, the traffic patterns, and the tolerance for risk.
Plan the schema change first. Decide the column name, type, nullability, and default values. Avoid nulls if possible; defaults make backfills easier. Document the reason for the new column so future maintainers understand the intent.
Then choose the safe migration path. In PostgreSQL, adding a column without a default is typically fast, but backfilling millions of rows will lock writes if done in one transaction. Break it into batches, or run async background jobs. In MySQL, ALTER TABLE can rebuild large tables. Use online DDL tools like gh-ost or pt-online-schema-change to avoid blocking.