Adding a new column should be simple. Yet in most systems, it triggers warnings about performance, migration downtime, and code changes that cascade through the stack. The challenge is not the SQL syntax. It is introducing schema changes without blocking reads, without locking writes, and without breaking production.
At the database layer, a new column can be added with an ALTER TABLE statement. In PostgreSQL, this is lightweight if you add a nullable column without a default value. The database only updates metadata. If you add a default, the engine rewrites the table, which means heavy I/O and potential locks. In MySQL, behavior differs between storage engines and versions, so reading the release notes matters.
But schema changes do not happen in isolation. The application code must handle the existence of the new column from the moment it appears. That means deploying application changes before the column is live, or ensuring backward compatibility so old code can run against the new schema.
Rolling changes in production requires coordination. Feature flags can hide partial functionality until the entire path is ready. Migrations can be split into multiple steps: first add a nullable column, then backfill data in controlled batches, and finally enforce constraints or defaults. This removes downtime risk while keeping the system responsive.