The table was running hot and the query plans were spiking. You knew it was time to add a new column.
A new column changes the shape of your data. It can unlock new features, fix broken assumptions, and speed up the work of your backend. But it can also bloat indexes, slow writes, and break downstream consumers if applied carelessly. The decision is cheap to type but heavy in effect.
Before adding a new column in SQL, decide its exact type, nullability, and default value. Pick names that carry meaning without ambiguity. Avoid storing derived fields unless you must—computed values belong in queries or materialized views.
Once defined, apply the change in a way that avoids locking tables for too long. In PostgreSQL, adding a nullable column with no default is instant. Adding a default without NOT NULL can still be fast in newer versions. But wide updates on massive datasets may need online schema migration tools to prevent downtime.
Review impacts on indexes. Unless the new column is a primary search vector, don’t index it yet. Indexes speed reads but slow inserts and updates. Measure actual query patterns before deciding.