Adding a new column should be simple. In practice, it often triggers a wave of downstream failures — migrations that stall, queries that no longer match, and code paths that silently skip the new data. The fastest teams treat the schema as code. They track changes in version control, enforce reviews, and deploy with zero-downtime patterns.
A new column in SQL means altering the table definition. In PostgreSQL, ALTER TABLE ... ADD COLUMN is straightforward, but in production, the move is never without risk. Storage impact, default values, triggers, indexes — each must be considered. Adding a nullable column is safest. Populating it should be a separate, idempotent step. Avoid defaults in heavy tables unless you can tolerate locks.
In systems with large datasets, run additive changes first. Deploy the code that can read the new column before you write it. This prevents runtime errors and guards against schema drift. Validate that your ORM or query builder doesn't choke when columns appear unexpectedly. If you use SELECT *, stop. Enumerate fields so your application contracts are explicit.