It sounds simple. But adding a new column to a production database can break queries, trigger long lock times, or slow the next deploy. The impact depends on the size of the table, the type of column, the defaults, and the database engine. Done carelessly, it can take down your app. Done right, it’s just another change in your schema history.
Start by defining the purpose of the new column. Know exactly what data it will store, its type, constraints, and whether it allows nulls. Add only what you need. Every column increases storage and index size, so keep it lean.
For MySQL and PostgreSQL, adding a nullable column without a default is fast. The database updates metadata instead of rewriting the table. Adding a non-nullable column with a default is slower in older versions, because the system rewrites each row. In PostgreSQL 11+, adding a column with a constant default is nearly instant, but don’t assume—check the docs for your version.
When changing large tables, avoid schema locks that block reads and writes. Use online DDL tools or run migrations in steps. Create the column first. Backfill data in small batches. Then add constraints or indexes once the table is ready.