A new column can change everything. One migration, one schema update, and the shape of your data shifts. The stakes are real: column changes ripple through application logic, APIs, analytics, and caching layers. If you get it wrong, production breaks. If you get it right, new features deploy clean and fast.
Adding a new column in SQL is simple in syntax, never in consequence. ALTER TABLE users ADD COLUMN last_login TIMESTAMP; looks harmless. Behind it are questions you have to answer before running the command. How will indexes handle it? Does the default value lock the table? Will your ORM pick it up automatically, or will serializers fail silently?
Plan for the storage impact. A nullable column in PostgreSQL is cheap in theory, but default values can rewrite the table and cause downtime. MySQL may behave differently, and in high-traffic systems every lock is expensive. If the column is part of a critical query path, benchmark before production.
Deploy in safe steps. First add the new column as nullable. Backfill data asynchronously. Then switch constraints to NOT NULL or add indexes after backfill completion. This avoids full table locks on hot paths. Use transactional DDL when supported, but test rollback behavior.