You issue one: add a new column.
This simple change can break production or unlock new capabilities. The difference is in how you plan, execute, and verify.
When adding a new column, start with purpose. Define the value this column will hold, the constraints, and the type. Use explicit data types—avoid implicit conversions. Consider nullability early; retrofitting NOT NULL later can force expensive migrations.
In relational databases like PostgreSQL or MySQL, adding a new column to a large table can lock writes. Even small changes can trigger full table rewrites if defaults or complex expressions are involved. For high-traffic systems, use transactional DDL only if you can tolerate locks. Otherwise, apply phased migrations: create the column without constraints, backfill data asynchronously, enforce rules in a second step.
For schema-managed systems, make sure your ORM model and migration script match exactly. Auto-generated migrations can introduce subtle drift if field definitions or database defaults differ. Always check the generated SQL before running it in production.