Not tomorrow. Not after a sprint planning session. Now. You open the schema, review constraints, scan dependencies. Adding a column looks simple, but every row and every query will feel it. A careless migration can lock writes, stall reads, or break the outputs your API depends on.
A new column is more than a field. It changes storage, indexing, and query cost. In relational databases, ALTER TABLE commands can trigger a full table rewrite. In NoSQL systems, adding a property affects how documents serialize and how downstream services parse them. Whether it’s PostgreSQL, MySQL, or MongoDB, you need to understand the operational impact before running the change.
Plan the migration. In production, use tools and strategies that avoid downtime—online schema change utilities like pt-online-schema-change, gh-ost, or native features such as PostgreSQL's concurrent builds. When possible, make the new column nullable first, then backfill data gradually with batch jobs. This reduces lock contention and avoids long transactions.