Adding a new column sounds simple. It is not. The decision touches schema design, migration strategy, query performance, indexing, and storage. Handle it poorly and you introduce downtime, lock tables, or cause silent data corruption. Handle it well and the change becomes invisible to users, while unlocking new features instantly.
A new column should begin with clear intent. Define its data type precisely. Avoid overbroad types like TEXT or VARCHAR(MAX) without reason. Consider nullability early—do you allow nulls or enforce defaults? A NOT NULL column on a large table can lock writes during migration unless added with a default value or performed in phases.
For live systems, online schema change techniques are essential. Use tools like pt-online-schema-change for MySQL or ALTER TABLE ... ADD COLUMN with LOCK=NONE when supported. In PostgreSQL, adding a nullable column without default is fast. Adding a default writes the value to every existing row, which may require batching or using DEFAULT with NOT NULL in separate steps.
Do not forget indexes. Indexing a new column on a large dataset can be the slowest part of the change. Build the index concurrently if your database supports it. Measure the effect on query plans and cached queries before pushing to production.