The query ran clean, but something was missing. The report needed one more field, one more piece of data. You needed a new column.
Adding a new column is one of the most common changes in a database. It looks simple, yet it can break performance or block production if handled carelessly. Whether you use PostgreSQL, MySQL, or a cloud service, the steps and implications matter. Schema changes ripple through deployments, migrations, and application code.
In SQL, the syntax is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This line is fast in small datasets, but on a table with millions of rows, it can lock writes, cause replication lag, and impact availability. The choice between a nullable column, a default value, or a generated column shapes the storage footprint and query plans.
For PostgreSQL, adding a column with a default value writes the value to every row, which can be slow. Instead, add the column as nullable, backfill in batches, then set the default. MySQL behaves differently; an ALTER TABLE may rebuild the table entirely depending on engine and version, so use tools like pt-online-schema-change to prevent downtime.