Adding a new column is simple when the database is quiet. In real systems, it often isn’t. Schema changes can lock tables, stall queries, and trigger unintended behavior in dependent services. The safest path is to plan the change, write a migration that handles both old and new states, and deploy in a way that keeps the application responsive.
Start by defining the new column with the correct type, default values, and nullability. Avoid wide types when a narrower one will fit. Choose constraints carefully—adding a NOT NULL column with no default will cause inserts to fail until you update all records. Index only if the new column will be used in frequent queries. Index creation can be expensive and should be timed to avoid peak load.
For production environments, consider using online schema change tools. They create shadow tables, copy data incrementally, and swap them in with minimal downtime. This approach prevents long locks on critical tables. Ensure application code is forward-compatible—reading from both old and new columns if necessary—before deploying schema changes.