A new column can break production if you rush it. It can lock tables, kill performance, or corrupt data under load. Every database engine treats schema changes differently. Some are instant; others rewrite the whole table. You need to know how yours behaves.
First, define why this column exists. Avoid adding columns as a shortcut for poor modeling. Check if the data belongs in a related table instead. If you proceed, pick the right data type. Too wide wastes space and slows scans. Too narrow means migrations later. Favor explicit types over generic ones like TEXT or STRING.
For live systems, use an online schema change process. Tools like gh-ost or pt-online-schema-change can add a new column without locking writes. In PostgreSQL, adding a nullable column with a default NULL is fast. Adding with a default value rewrites the table—avoid that on large datasets. Always test the migration plan in staging with production-sized data.