Adding a new column to a live database is rarely just one command. You have to plan for data integrity, migration time, and application downtime. The wrong approach locks tables, blocks queries, and triggers alerts from every layer of the stack. The right approach makes the change invisible to users and safe for the system.
A new column can mean a schema update in PostgreSQL, MySQL, or any relational store. It might be a field addition in a NoSQL document. In either case, start with version-controlled migration scripts. Apply the change in a staging environment with real data volume. Measure the migration window. Identify blocking transactions.
For SQL databases, ALTER TABLE ... ADD COLUMN is simple, but on large tables it can be expensive. Some engines rewrite the entire table. Others allow instant adds if you provide a default of NULL and no constraints. To avoid long locks, add the column without a default, backfill in batches, then set the default at the schema level. If you need the column to be NOT NULL, enforce this after the backfill completes.
For production-grade changes, wrap this process in feature flags. Deploy application code that ignores the column until the database schema exists everywhere. Roll out reads and writes in phases. This prevents race conditions where some nodes expect the column and others do not.