The query ran. The data looked wrong. A new column was the fix.
Adding a new column is one of the most common changes in database evolution. It is simple to describe but dangerous to run at scale. The choice between nullable and non-nullable, default values, and data type constraints can decide whether deployment is instant or blocked for hours.
In relational databases, a new column changes the schema, the contract all queries depend on. For PostgreSQL, adding a nullable column without a default is usually fast because it updates only the metadata. Adding a column with a default value rewrites the entire table, which can lock writes for a long time. For MySQL, the performance and locking behavior depend on engine type and version; InnoDB online DDL can help, but only if the operation is configured to avoid table copy.
When adding a new column to a production system, migrations must be planned. First create the column as nullable. Then backfill data in small batches to avoid write spikes. Finally update constraints and defaults when the data is ready. This three-step process reduces locking and keeps services available.