The dataset was clean. But the schema had changed, and nothing matched. The fix started with a new column.
Adding a new column to a database table looks simple. It isn’t. Done right, it preserves data integrity, avoids downtime, and scales under load. Done wrong, it locks writes, corrupts data, and kills throughput. The difference is process.
Start with the schema definition. In SQL, the command is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This works for small tables. For production systems holding millions of rows, you need an online migration. Tools like pt-online-schema-change or gh-ost let you add a column without blocking operations. They copy data into a new table with the column in place, then swap it in atomically.
Choose defaults with care. A nullable column is flexible but can break downstream code if not handled. A non-null column with a default avoids null checks but can mask missing data. Every new column changes storage, indexes, and query performance. Measure before and after.