The query hit the database, but the value wasn’t there. You need a new column.
Adding a new column sounds simple, but mistakes here can break production. The schema must change without locking tables for too long. Data must remain consistent. Queries must keep running.
First, decide the column’s type. This shapes storage, indexing, and performance. Wrong types mean wasted space or failed constraints. Define nullability. If it’s NOT NULL, plan the default value. Defaults must be cheap to apply at scale.
Use ALTER TABLE in a controlled way. On large tables, choose operations that avoid full table rewrites. Many relational databases support ADD COLUMN instantly if you don’t backfill immediately. For big datasets, backfill in batches to reduce load and avoid long locks.
Index only if necessary at creation. Every index adds write overhead. Often, you can deploy the column first, then add the index in a later migration. This spreads risk and speeds deployment.
Test on a staging environment with production-like data sizes. Measure query plans before and after. Confirm that applications handle rows with the new column both when populated and when empty.
Document the change in your migration logs. Track versioned schema changes in code so the state of the database is always tied to the running build. Avoid making columns in production without review and automation.
A new column is more than a single command. It’s a change in the structure of your system. Done right, it ships fast and safe. Done wrong, it causes downtime and data loss.
See how to create, migrate, and deploy a new column without downtime. Try it live in minutes at hoop.dev.