The query runs. The data lands. But the schema just changed, and the system is already breaking. You need a new column.
Adding a new column in production is not a formality. It touches schema management, migrations, performance, and data consistency—especially when handling large datasets or high-traffic applications. Done wrong, it can lock tables, slow queries, or corrupt writes. Done right, it is invisible to the user and safe at scale.
First, decide if the new column should be nullable, have a default, or be computed. Adding a column with a non-null default in some databases rewrites the entire table, which can be expensive. In Postgres, for example, adding a nullable column or a column with a constant default is fast, but a computed default can trigger data rewrite.
For MySQL, use ALTER TABLE ... ADD COLUMN with care. Online schema change tools like gh-ost or pt-online-schema-change can keep operations online. For large tables, schedule schema changes during low load, or use migration tools that chunk the operation. Always test these on replicas before production.