When a database evolves, adding a new column is one of the most common migrations. It can be simple, but the cost of doing it wrong can leak into production, slow queries, and lock tables at the worst possible time. A new column changes the shape of data. Every read and write path should know it before the change ships.
Start with your migration script. Define the new column with the correct data type and constraints. If the column will hold user-facing data, set NOT NULL and provide a safe default. If it’s optional, still decide whether future values might need indexing. Adding an index later under load will hurt more than planning it today.
Run the migration in a staging environment with production-scale data. Measure the lock time. In PostgreSQL, a simple ALTER TABLE ADD COLUMN without a default is fast, but adding a default rewrites the table. For massive tables, consider adding the column without the default, then backfilling in small batches to avoid downtime.