Adding a new column sounds trivial. In practice, it can be a fault line in your system. Schema changes touch live data, locked queries, migrations, and application code. Done wrong, they create downtime or corrupt production records. Done right, they are invisible and safe.
A new column should start with a clear definition: name, type, constraints, default values. Avoid guesswork. Match the data type to its future use, not just current needs. If it will store timestamps, use a proper timestamp type. If it must be unique, enforce that at the database level.
For SQL databases, use ALTER TABLE with care. Large tables can take minutes or hours to change. Online schema change tools, such as pt-online-schema-change or native database features, help avoid locks and blocking. Some systems, like PostgreSQL, can add a nullable column instantly, but adding NOT NULL with a default can be slow. Test with realistic data sizes.
In distributed systems, coordinate migrations with application deployments. Ship code that can handle both the old and new schema. Add the new column. Populate it in batches. Switch the application to use it. Only then remove deprecated columns. This is the expand–contract pattern, and it lowers risk to production.