Adding a new column starts with knowing why it exists. Is it for indexing? Tracking state? Supporting a new feature? Without clarity, you invite bloat and performance decay. Every column consumes storage. Every column changes insert and update costs.
In relational databases, the ALTER TABLE command is the standard path. But the impact varies by engine. In PostgreSQL, adding a column with a default value rewrites the table, locking writes. In MySQL, depending on version and storage engine, it can be near-instant or painfully slow. In distributed databases, schema evolution can cause cluster-wide synchronization delays. Understand the behavior before you run the command.
Data type matters. Pick the smallest type that holds your value. Use nullable columns intentionally; NULL-heavy columns take space and complicate queries. Indexing a new column can improve lookups, but every index slows writes. Avoid premature indexing. Profile first.
Backfill with care. For large datasets, a full backfill in one transaction risks lock contention and replication lag. Use batched updates, and monitor the replication queue. In critical systems, consider dual-writing the new column from application code before cutting over.