Adding a new column is simple in theory but complex in practice. Schema changes can lock tables, stall queries, and cause downtime if done without planning. The moment you execute ALTER TABLE ADD COLUMN, you change the shape of your data forever.
In production systems, a new column is rarely just a line of SQL. It triggers considerations for indexing, nullability, default values, and backfilling. You must confirm how the application will use it, ensure backward compatibility, and account for reads and writes during the change. In distributed systems, this means coordinating schema updates alongside application rollouts to avoid breaking queries.
For relational databases, adding a new column with a default value can rewrite the entire table. Without that default, the column may be fast to add, but the burden shifts to the application layer to handle nulls. In PostgreSQL, version matters; newer releases can add certain defaulted columns without a full rewrite. MySQL and MariaDB have different behaviors depending on storage engines.
Indexing the new column should only happen after it is populated and stable. Creating indexes during peak hours risks lock contention. For high-throughput systems, consider online index creation or incremental rollouts.