Every engineer knows this moment. It looks simple. It never is. A new column can change query plans, affect indexes, add migration time, and touch every downstream system that reads the table. If the table is large, a single ALTER TABLE without planning can lock writes, cause outages, or blow up replication lag.
The first step is understanding the impact on the existing schema. Review table size, read/write patterns, and constraints. If the new column needs a default value, decide whether to set it at creation or backfill it in batches. The wrong choice can block production traffic.
In PostgreSQL, adding a nullable column without a default is fast—it only updates metadata. Adding a NOT NULL column with a default will rewrite the table. Use ALTER TABLE ... ADD COLUMN carefully and check the execution plan if your system has online DDL capabilities. MySQL, MariaDB, and other engines differ in performance depending on the storage engine.
Adding indexes for the new column should be deferred until after the column is in place and the data is backfilled. Building an index on a billion rows is another operation that must be planned off-peak or done concurrently when the database supports it.