The migration had stalled. The old table structure could not handle the demands of the new feature, and the answer was clear: a new column.
Creating a new column in a production database sounds trivial. It isn’t. Done wrong, it can lock tables, block writes, and bring down critical paths. Done right, it becomes invisible, a precise extension of your schema that the system absorbs without friction.
The first step is defining the purpose of the new column. Every column must justify its existence. Determine the exact data type, constraints, and indexing strategy before you touch the schema. A clear specification stops scope creep and avoids the common trap of overloading a column with mixed responsibilities.
When adding a new column in SQL, the usual form is straightforward:
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMPTZ;
In a local environment, this runs instantly. In production at scale, the same command can trigger full-table rewrites. For PostgreSQL, use ADD COLUMN without a DEFAULT on existing rows to prevent the rewrite. Then backfill values in controlled batches.