The schema is broken. Your data needs a new column.
Adding a new column is one of the simplest changes in theory, but it can wreck performance, trigger migrations that lock tables, and force downstream systems to adapt. Small error, big blast radius. Treat it as a surgical operation.
Start with the definition. In SQL, a new column can be added with ALTER TABLE and a precise data type. Avoid generic types unless you understand the trade-offs. Precision matters—integers instead of text for IDs, proper timestamps instead of strings. In NoSQL systems, a “new column” may mean extending documents with an extra field, but it still impacts queries, indexes, and storage.
Check constraints before pushing. Does the column need NOT NULL? Will it require a default value? Defaults can lock the table during write operations in some engines. Always run this change in staging with production-load traffic simulations.
Plan for migration timing. If the table is large, adding a column can be expensive. Use online schema change tools when supported. Split the migration into two steps: add the column with nulls, then backfill in batches. This reduces lock contention.