The query had been running for hours when the alert hit. The database was slow, and no one could say why. Then someone noticed: a missing column. It was time to add a new column, fast.
Creating a new column is not just a schema change. Done wrong, it stalls production, locks tables, or corrupts data. Done right, it happens in seconds with zero downtime. Whether in PostgreSQL, MySQL, or a distributed datastore, the goal is the same—add the new column while keeping the system online.
First, define the column type precisely. An integer is not a bigint. A nullable string is not a fixed char. Misjudging data type size leads to wasted storage or unexpected constraints. Use ALTER TABLE with care. In some systems, adding a column with a default value rewrites the entire table. This is the moment that crushes performance if overlooked.
In PostgreSQL 11+, adding a new column with a constant default no longer rewrites the table. Instead, it stores the default as a metadata entry until rows are updated. In MySQL, ALTER TABLE can still block writes on large tables unless run online. Use ALGORITHM=INPLACE when supported or partition migration when not. In distributed databases, such as CockroachDB, schema changes run as background jobs, but observe the job queue to ensure completion.