A new column can break queries, corrupt migrations, and slow down critical paths. It can also unlock capabilities you could not ship before. The difference is in how you plan, implement, and deploy it.
When adding a new column to a production database, the first step is to decide its data type with care. Avoid types that will require large rewrites later. Use defaults only when necessary, as they can lock tables during creation in some databases. Null columns are often safer for live systems during initial rollout.
Always add the new column in a non-blocking migration. For high-traffic systems, split the work: alter the table in one migration, backfill in batches in another, then switch application reads and writes in a final deployment. This reduces lock time and lowers the risk of downtime.