The query was slow. The table was large. You needed a new column, and you needed it now.
Adding a new column is one of the most common schema changes in any database. It sounds simple. It rarely is. The impact can cascade through queries, indexes, application code, and downstream analytics. Get it wrong and you stall deployments, break integrations, or lock tables in production.
The first step is to decide the type. Use native types whenever possible to leverage the database engine’s indexing and storage optimizations. For large-scale production workloads, avoid null columns unless they convey precise meaning. Default values can prevent unexpected failures in legacy codepaths, but they require forethought to avoid extra write load.
Execution depends on your migration strategy. In PostgreSQL, ALTER TABLE ADD COLUMN is fast for metadata-only changes, but becomes blocking for defaults or computed values. In MySQL, versions before 8.0 may rebuild the table for certain column types, impacting availability. Understand your engine’s DDL behavior and plan accordingly.