Adding a new column to a production database is high-stakes. Done wrong, it can lock tables, slow queries, and break downstream code. Done right, it gives you room to evolve your data model without downtime. The difference comes down to understanding the database engine, your schema migration process, and the real-world load your system handles.
A new column should never be an afterthought. Start by defining the exact data type, default value, and nullability. In PostgreSQL, adding a nullable column without a default is fast, because no table rewrite is needed. But adding a column with a default on a large table will rewrite every row, which can halt production if you are unprepared.
For MySQL and MariaDB, online DDL options allow you to add columns with less locking, but you still need to test on a realistic dataset. Consider adding the column in multiple steps: first add it as nullable, then backfill in batches, and finally set constraints or defaults. Even in cloud-managed systems, migrations can trigger hidden costs from increased I/O and replication lag.