A new column sounds simple. In practice, it changes the shape of your data and the behavior of your application. You must track type definitions, default values, constraints, and how backfilling interacts with traffic. Good systems handle this without service interruption. Weak systems fail silently or lock entire tables.
To add a new column to a relational database in production, you first define the migration. This can be an ALTER TABLE statement in SQL or a migration file in your framework. For large datasets, you must avoid locking. Strategies include creating the column without a default, writing a migration script to populate it in batches, and then altering constraints after the fact.
Adding a new column in distributed systems is harder. You cannot assume all nodes see the change at the same time. Feature flags and dual writes are common patterns. The application needs to handle the interim state when the column exists in some places but not others.