The query ran. The table returned. But the data was missing a critical piece. You need a new column.
Adding a new column is one of the most common schema changes in modern databases. Done right, it’s fast and safe. Done wrong, it can lock tables, block writes, or trigger outages. Whether you’re working with PostgreSQL, MySQL, or cloud-native data warehouses, the process follows the same core steps: define the new column, set its type, handle defaults, migrate existing rows if needed, and deploy without downtime.
In PostgreSQL, a simple ALTER TABLE users ADD COLUMN last_login TIMESTAMP; works in most cases. This runs instantly if no default is set. Adding a default that’s not NULL can cause a full table rewrite in older versions, so always check the version-specific behavior. Avoid locking large production tables during peak hours.
For MySQL, ALTER TABLE users ADD COLUMN last_login DATETIME NULL; is the equivalent. In recent MySQL versions with ALGORITHM=INPLACE or ALGORITHM=INSTANT, schema changes can execute without blocking reads and writes. But test this in staging because storage engines, foreign keys, and triggers can affect execution plans.