A new column alters the shape of the truth your application runs on. When you add one to a table, you change how queries behave, how indexes perform, how migrations roll forward and back. A careless default can cause downtime. A mismatched type can corrupt stored data. Even a null value can crash production if the code assumes otherwise.
Best practice: define the column explicitly. Know the exact data type and constraints. Decide if it needs NOT NULL. Set a safe default that will not mislead analytics or reporting. On large tables, consider online schema changes to avoid locking writes. Review replication lag before applying changes in distributed systems.
Test every alteration in staging with production-scale data. Measure query planners to see how the new column affects performance. If you index it, verify that the index improves real workloads, not just synthetic tests. Create rollback steps before deploying, so you can revert the schema without data loss.