The query ran for hours. Nobody spoke. Everyone knew the schema was wrong, but nobody wanted to touch it. Then the decision came: add a new column.
A new column sounds simple. It often isn’t. In production databases, it means changing the contract between code and data. Adding a column forces you to think about null handling, backward compatibility, default values, and index impact. It forces you to check every place in the application and every downstream integration where data flows.
The first step is defining the purpose of the new column. Avoid vague names; pick a name that matches its role exactly. Decide the data type with precision. Strings where integers should be will cost you later. For numeric fields, pick the lowest type that can hold your largest possible value. For dates and times, choose based on timezone behavior and storage needs.
Next, plan the migration. Adding a new column in a large table can lock writes, even in systems that claim "online DDL". Test the change in a staging environment with realistic data volumes. Measure how long the migration script takes. If you must backfill data, do it in chunks to reduce transaction locks.