Adding a new column in a production database is simple in theory but full of traps in practice. Schema changes impact performance, uptime, and application logic. Done wrong, they lock tables, slow queries, and break deployments. Done right, they happen fast and invisibly.
A new column should begin with a clear definition: name, data type, default value, and nullability. Avoid vague types. Choose constraints that match actual data rules. Document why it exists before adding it—future changes will depend on this clarity.
In relational databases like PostgreSQL or MySQL, ALTER TABLE is the standard way to add a column. But direct ALTER TABLE in large datasets can trigger long locks. Use ADD COLUMN with defaults carefully. Some engines rewrite the entire table when you set a non-null default, causing downtime. Modern migrations solve this with phased changes: add the column nullable, backfill data in batches, then enforce constraints.
For distributed systems or microservices, coordinate schema changes across services. A new column in one place often means code updates elsewhere: ORM models, serialization, API contracts, and ETL pipelines. Deploy migrations first, then code that writes to the new column, then finally code that reads from it.