Adding a new column looks simple. It rarely is. Schema changes touch storage, indexes, queries, and application code. Done right, it is fast, safe, and invisible to users. Done wrong, it can lock tables, stall writes, or crash services.
First, know the type. Use the smallest data type possible for the new column. This reduces storage cost and speeds reads. Decide if NULLs are allowed. Default values can prevent errors for existing rows but may increase migration time on large datasets.
Second, plan the migration. For small tables, a direct ALTER TABLE is fine. For large tables or systems under heavy load, use an online schema change tool. Tools like pt-online-schema-change or native database features keep the table writable during changes.
Third, update application logic. Add the new column to all relevant SELECT, INSERT, and UPDATE statements. Avoid deploying code that writes to a column before the column exists. In distributed systems, use feature flags or phased rollouts to avoid race conditions.