Adding a new column is simple in theory, but dangerous in production if you move without a plan. Schema changes touch every request, every index, every deployment. Done right, they unlock new features, tighter analytics, better scaling paths. Done wrong, they lock up your system and force a rollback in the middle of peak traffic.
In SQL, the core operation is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This command adds the new column to the users table. The execution time depends on the database engine, the table size, and whether the engine supports online DDL. MySQL with ALGORITHM=INPLACE or PostgreSQL with default settings for NULL columns can make this operation fast. But beware: adding a non-nullable column with no default may rewrite the whole table, blocking writes and reads.
In distributed systems with replicas, the new column must propagate cleanly. Mismatched schemas between nodes can break application logic if the ORM or query layer assumes synchronized column availability. Deployment strategies often break the change into phases: