A new column can be simple or it can destroy performance. The difference is in how you design, migrate, and deploy. In relational databases, a poorly executed schema change can lock tables, block writes, and slow queries. In distributed systems, it can ripple through caches, indexes, and services.
Start with the schema definition. Decide if the new column is nullable, if it needs a default value, and how it should be indexed. Avoid adding non-null columns with no defaults to large production tables in one step—this can trigger a full table rewrite.
Plan your migration. If your database supports online schema changes, use them. In MySQL, consider ALGORITHM=INPLACE or ALGORITHM=INSTANT where available. In PostgreSQL, adding a nullable column without a default is fast, but beware of operations that rewrite rows. For indexed columns, create the index in a separate migration to keep locks minimal.
Update your application code to handle the existence of the column before you backfill data. Deploy read paths first, then write paths. This allows older app versions to coexist with the migration and prevents runtime errors in rolling deployments.