The database shook when the new column appeared. Code froze. Migrations stacked in queues. Every query plan shifted. Adding a new column can be a small change or a breaking one, depending on how you do it. The difference is in precision and timing.
A new column in a schema changes the contract between storage and application. Even if it holds NULLs now, its existence alters how data is read, written, and indexed. In production systems, the goal is zero downtime. That means you add the new column without locking writes, without forcing full table rewrites, and without breaking backward compatibility.
Plan the change in stages. First, deploy the schema update. Avoid blocking operations by using non-locking ALTER commands where supported. For large tables, that means chunked migrations or online schema change tools. Second, deploy application code that can handle both the old and new schema states. Feature flags or conditional reads can help. Only once the code reads and writes the new column should you make it required or add constraints.