A new column is never just another field in a table. It changes contracts, alters queries, and can break production if handled poorly. To get it right, treat schema changes as code: explicit, versioned, and tested before release.
Start by defining the new column in a migration file. Name it clearly. Use a data type that matches its purpose and expected range. If it carries critical data, make it non-null with a default value to avoid partial writes.
Run the migration on a staging database that mirrors production size. Time the operation. Check indexes. Adding an index at creation avoids later locks, but be aware of write performance costs. For high-traffic systems, break the rollout into stages: add the new column with null values, backfill in small batches, then enforce constraints.