Adding a new column is simple to describe and dangerous to execute at scale. It is a schema change that touches production data. It can lock tables, block queries, and cause downtime if run without care. Yet every growing system eventually needs it—tracking a new metric, storing a new identifier, enabling a new feature.
The key is understanding how your database engine handles schema changes. In Postgres, ALTER TABLE ... ADD COLUMN is fast when adding a nullable column without a default. But adding a column with a default value rewrites the table, which can be slow on large datasets. MySQL and MariaDB behave differently depending on the storage engine and version; online DDL can minimize downtime but must be tested.
Plan each new column with precision. Choose the data type carefully to avoid future migrations. Set NULL defaults where possible during the initial deployment, then backfill data in batches. Avoid blocking schema changes during peak traffic. Wrap it all in feature flags so the application reads and writes to the new column only when ready.