The schema was not. You needed a new column, and nothing else would do.
A new column changes the structure of your data. Done right, it opens new possibilities. Done wrong, it slows queries, breaks services, or triggers downtime. The process is simple in syntax, but the consequences are real.
In SQL, adding a new column is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
But in a live system, that command can lock the table or strain replication. On massive datasets, a blocking alter can freeze production for hours. This is why zero-downtime schema changes matter. Use tools designed for online migrations. Test each step in staging. Keep track of default values and nullability to avoid surprises.
When designing a new column, consider type, size, and indexing. Choose data types that match the smallest needed size. Avoid adding indexes until usage patterns prove the need. Store timestamps in UTC. For boolean or enum-like fields, decide how they will evolve over time—migrations are easiest when changes are predictable.