A new column can change everything in a database table. It can speed up delivery of features or grind an application to a halt. Impact scales with the size of the table, the indexes in play, and the patterns of reads and writes hitting it every second. Adding it is simple in syntax, but the choice of type, nullability, and default values determines the cost of the migration.
Schema changes lock rows, block transactions, and trigger full table rewrites if defaults are non‑null. In production, that means downtime unless the migration is done in a controlled way. On large datasets, avoid adding a column with a non‑null default in a single statement; instead, add it as nullable, backfill in batches, and finally alter constraints.
Indexing a new column brings its own weight. Each index increases write overhead and consumes storage. If the new column is used in filters, sort operations, or joins, choose the right index type — b‑tree, hash, or GIN — to match the query patterns. For columns used in partial workloads, partial indexes limit the cost.