A new column in a database table is never just a new column. It changes queries, indexes, memory profiles, and replication lag. It can lock tables. It can trigger code paths you forgot existed. In production, even a single ALTER TABLE can cascade into application downtime if planned poorly.
Engineers add new columns for many reasons: feature flags, tracking fields, denormalizing slow joins, archiving status changes. Yet the technical impact is rarely just a schema change. Adding a column means planning for data type size, nullability, default values, and whether the operation is blocking or non-blocking. It means knowing how your database engine handles DDL under load.
In PostgreSQL, adding a nullable column without a default is instant. Add a default to a large table and you might lock writes for minutes or hours. MySQL behavior differs. Some managed services patch over these issues, but many do not. Always benchmark against production-scale data.
Indexes are another trap. A new column that you intend to query often should be indexed, but creating an index on a giant table is not free. Even with CREATE INDEX CONCURRENTLY, you can see performance degradation. Plan index creation in deployment windows.