Adding a new column sounds simple. In production, it can be dangerous. Schema changes can lock tables, block queries, and cause downtime if done wrong. Precision matters. You need speed without sacrificing safety.
A new column changes the shape of your data. It lets you store more variables, track new states, or support new features. Before you run an ALTER TABLE in production, you must know how the database engine will execute it. Some engines perform it instantly for nullable or default columns. Others rewrite the entire table.
In PostgreSQL, adding a nullable new column with no default is fast. But adding it with a default value rewrites the table, which can lock writes for large datasets. In MySQL, online DDL can help, but requires the right storage engine and flags. Plan the change. Test it on realistic dataset copies. Measure the time.
If you need the value for the new column for every row, consider creating it nullable, backfilling in small batches, then enforcing constraints or defaults. This approach avoids long locks and keeps your app responsive. For NoSQL systems, adding a new field may be schema-less, but your application code still changes shape. Deploy both carefully.