The requirements hit the table fast: you need a new column. Not in theory, not in a spec doc—right now. The database is live, code is shipping, and the schema must change without breaking production.
A new column sounds simple until constraints appear. Foreign keys, indexes, triggers, migrations, replication lag—these decide whether a column is seamless or catastrophic. The core decision is how to add it without downtime and without locking the table for minutes or hours.
In relational databases like PostgreSQL and MySQL, ALTER TABLE ADD COLUMN works, but the execution path varies. If the column has a default value and NOT NULL constraint, the database must rewrite all rows. That rewrite can stall queries and block writes. Adding the column as nullable, then backfilling the data in small batches, followed by a constraint, often avoids locking the table.
For distributed systems, consider forward-compatible schema changes. Deploy code that reads the new column only after it exists, and writes to it while keeping the old path intact. Then migrate traffic gradually. This reduces risk in environments with multiple replicas or microservices consuming the same data.