Adding a new column is one of the most common changes in a database schema. It looks small. It can be dangerous. Done right, it unlocks new features and clean logic. Done wrong, it stalls deployments and corrupts data.
Start with the schema definition. In SQL, the ALTER TABLE statement is the weapon of choice:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This works in PostgreSQL, MySQL, SQLite, and more. But the execution plan changes with engine and scale. In large tables, adding a column with a default value can lock writes. On high-traffic systems, locks can last seconds or minutes. That’s enough to trigger failures.
Avoid downtime by using migrations designed for zero-lock execution. Many ORM frameworks have migration tools, but they are not equal. Inspect the generated SQL. Control the defaults. If you must backfill data, do it in small batches, not in one transaction.
Think about nullability. A nullable new column avoids forced writes on creation, but demands null checks everywhere. A non-nullable column ensures consistent data but requires a default or backfill process before enforcement. Match the constraints to the use case, not to habit.