A single command can change the shape of a database. Adding a new column is one of those commands. Done well, it adds power without breaking what came before. Done poorly, it slows queries, locks tables, and burns deploy time.
A new column is not just extra data. It is a schema change with impact. You choose the name, the type, the default. You decide if it can be null or if it must hold a value. Each decision affects indexes, storage, and migration speed. The database engine will rewrite pages on disk. It may block reads or writes if not planned.
Best practice: add columns in a way that avoids downtime. In PostgreSQL, adding a nullable column without a default is fast. Adding a column with a default on a large table triggers a full table rewrite. MySQL behaves differently depending on the storage engine and version. For high-traffic systems, you should stage the change: first add the column as nullable, then backfill data in small batches, then enforce constraints.
In production, a new column ripples beyond the database. Application code must handle the new field. APIs must serialize and validate it. Downstream consumers need to understand the change before it goes live. Without coordination, one simple schema change can derail a release.