The database waits, but the query fails. You read the error again. The table needs a new column.
Adding a new column is simple in theory, but the impact can be deadly if done wrong. Every schema change is a contract change with your data. Done well, it unlocks features. Done poorly, it breaks production.
First, decide on the column name and data type. Pick names that are exact and durable. Avoid adding columns for unclear future needs; each field should have a defined purpose. Map the type to your application layer precisely—mismatches here cause silent data corruption.
When altering a live table, always test the migration on a staging database. Measure the cost of the ALTER TABLE operation—especially for large datasets. Some systems lock tables, others rewrite them in place. Plan for downtime or use an online schema change tool.
Set defaults carefully. NULL is not always safe. Default values can fill existing rows instantly, but they may also mask logic errors in application code. Enforce constraints where possible to protect integrity at the database level, not just in the application.