When you create a new column in production, planning matters more than code. Define the exact data type. Avoid nullable fields unless they are intentional. Consider storage engines, collation, and precision. Be explicit about defaults. A new column without defaults can force updates to millions of rows, locking tables and blocking requests.
Test the migration on a copy of real data. Measure the execution time. Check how it interacts with existing indexes. Adding an index to a new column can speed up reads but slow down writes. If the column needs indexing, decide between B-tree, hash, or full-text based on query patterns. Watch for changes to query plans once the schema shifts.
Backward compatibility is critical. If you deploy application changes before the column exists, the code breaks. If you deploy the column before the code can handle it, you risk null pointer errors or undefined behavior. Use feature flags or phased rollout to keep both states working during the transition.