The table is empty, but the schema waits for you. You need a new column, and you need it fast. Everything depends on the right definition. One wrong choice, and the next migration could break production.
Adding a new column is not just typing ALTER TABLE. Data types, constraints, indexes, and defaults all matter. They define how storage works, how queries run, and how future changes will behave. A column must fit the database design without corrupting existing data. Planning saves hours lost to debugging.
Start with the name. It should be clear, short, and consistent with existing naming conventions. Then choose the type. INTEGER, TEXT, JSONB—each has trade-offs for performance and flexibility. Apply NULL or NOT NULL intentionally. Decide if default values are required to keep inserts valid. Use indexes only when they improve reads without slowing writes.
If the change is large, lock contention can become a threat. In high-traffic environments, migrations should be online, batched, or queued to avoid blocking. Test your migration script against a snapshot of production-sized data. Measure the impact. Roll out cautiously.