Creating a new column should be fast, safe, and reversible. In modern databases, this means understanding how the schema change will impact performance, queries, and downstream systems. Whether you work with PostgreSQL, MySQL, or a columnar store like ClickHouse, the process has risks: table locks, replication lag, and silent breaking of application code.
The simplest way to add a new column is through an ALTER TABLE statement. In PostgreSQL:
ALTER TABLE orders ADD COLUMN discount_rate numeric(5,2) DEFAULT 0 NOT NULL;
This works, but on large tables it can still cause blocking. Online schema change tools like pg_online_schema_change, gh-ost, or pt-online-schema-change allow you to create a new column without locking writes. In distributed systems, you also need to propagate the change through migrations in your deployment pipeline.
Column defaults, nullability, and constraints matter. Adding a NOT NULL column without a default will often fail unless you backfill data first. Backfills must be planned to avoid spikes in CPU and I/O. Some teams run them in batches, checking query performance after each step. Others use feature flags to roll out new column-based logic gradually.