Adding a new column is simple in syntax but unforgiving in practice. The goal is not just to append a field, but to do it without locking tables, corrupting data, or slowing queries in production. Schema changes are easy to break and hard to roll back. That is why planning matters.
First, decide on the column name, type, default value, and constraints. A new column in SQL should be explicit. Avoid ambiguous names. Think about nullability. If the column must be required, populate it first, then enforce NOT NULL to avoid downtime.
Second, choose an approach for altering the table. In MySQL and PostgreSQL, ALTER TABLE is common, but large datasets make this risky. For high-availability systems, use online schema change tools like gh-ost or pt-online-schema-change. They minimize lock time by copying rows in the background while writes continue.
Third, update application code to handle the column incrementally. Deploy backend changes that can read the new column before you start writing to it. This makes rollback safer and avoids breaking queries. Keep migrations idempotent so they can run more than once without damage.