Schema changes can look simple. One extra field. One quick migration. But if you run a production system with live traffic, a new column can trigger locks, replication lag, or performance cliffs. The cost is hidden until it shows up in monitoring or in an angry Slack channel.
When planning a new column in a relational database, first check the storage engine and table size. On large tables, additive schema changes can rewrite entire data files. Even if the column is nullable and has no default, the migration can still block. Assess your DDL strategy. Online schema change tools like pt-online-schema-change or built-in database features (e.g., PostgreSQL’s ADD COLUMN with defaults in later versions) can help avoid downtime.
Consider indexing strategy at the same time. Adding a new column might tempt you to add a new index. An unnecessary index can impact write performance and disk usage. Evaluate query plans before you commit. Run the migration on a staging environment with production-like data to see the effect on hot code paths.