A new column sounds simple. In reality, schema changes can break queries, lock tables, and slow production workloads. The method you choose matters.
When you add a new column in SQL, you must choose the right data type, default value, and nullability. For large tables, these decisions impact storage, index efficiency, and replication lag. Avoid default values on massive datasets unless you can tolerate a full table rewrite. Use NULL for faster operations when data can be backfilled later.
In PostgreSQL, ALTER TABLE ... ADD COLUMN is fast if you allow NULL defaults, but slow with non-null defaults. MySQL behaves differently; versions before 8.0 often require heavy locking, though InnoDB and instant DDL features in recent versions can mitigate downtime.
Adding a new column with computed data or constraints carries more risk. Triggers, views, and ORMs might need updates. Schema migration tools like Liquibase, Flyway, or native framework migrations can structure the rollout into safe steps. Blue-green deployments and feature flags give you control during live schema evolution.