The query ran. The table stared back, unchanged. It needed one thing: a new column.
Adding a new column is one of the most common database changes in production systems. It sounds simple. It is not. Done wrong, it can lock tables, drop queries, and bring down critical paths. Done right, it ships fast, with zero downtime, and supports new features without risk.
A new column alters the schema. In SQL, the syntax is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
On small tables, this runs instantly. On large ones, it can block writes or reads while the database rewrites rows. This is where strategy matters. Many teams use non-blocking schema changes or online migrations. Tools like pt-online-schema-change, gh-ost, or native database features like PostgreSQL’s ADD COLUMN with a default of NULL can help avoid locking.
Choosing data types is critical. Storing timestamps as TIMESTAMP WITH TIME ZONE avoids subtle errors with daylight savings. For integers, use the smallest type that holds your expected range. Adding NOT NULL constraints? Add them in a separate step after backfilling data to prevent long locks.