The logs said there was no column named status.
Adding a new column should be simple. In practice, the choice of method determines if you keep uptime or trigger a costly outage. Schema changes in production demand precision, not hope.
To add a new column in SQL, you use ALTER TABLE. The basic form:
ALTER TABLE users ADD COLUMN status TEXT;
This works, but it is not the full story. On large datasets, the operation can lock the table. That means writes and reads can stall. In high-load systems, this creates cascading failures. Avoid it by using online schema change tools or database-native features that support concurrent alters. MySQL offers ALGORITHM=INPLACE and LOCK=NONE. PostgreSQL can add nullable columns without a rewrite, but adding a column with a default value in older versions can still rewrite the table. Test on staging. Time the operation.
After creation, review your indexes. A new column without the right index can degrade query performance. Index creation can also block writes, so consider CREATE INDEX CONCURRENTLY in PostgreSQL or CREATE INDEX ... ALGORITHM=INPLACE in MySQL where supported.
Decide on data type and constraints early. Changing them later can be more expensive than adding them at the start. Enforce NOT NULL only after backfilling data, to avoid rejecting inserts from existing workflow paths.
Automate column creation and migration steps. Store migration scripts in version control. Use a migration runner that can apply them in a safe, reproducible way. Monitor latency, locks, and replication lag during the change. Rollback plans are not optional.
A new column sounds small. In production, it is a change to the contract between your database and your application. Treat it with the same discipline as you would a deploy of core business logic.
See how schema changes can be deployed quickly and safely. Try it live in minutes at hoop.dev.