The table waits. Empty, but not for long. You need a new column, and every second between idea and implementation costs value.
Adding a new column should be instant, predictable, and reversible. In most systems, it is none of these. Schema changes block writes. Data migrations bloat releases. One mistake in type or constraint means rollback hell. These delays slow teams and stall features. The fastest path is a workflow that treats schema as code and pushes it like any other change.
A new column starts at definition. Name it to match the domain, not the storage engine. Set the type for precision. Always define nullability and defaults. Avoid silent changes—document the reason for the column in version control. Once defined, the column should appear in development, staging, and production with the same command. No manual patches. No hidden steps.
Performance matters. Adding a new column to a massive table can lock up operations if done naively. Use migrations that run online. Write them to respect the size and load of the dataset. For very large datasets, split the migration into schema shape change and backfill, so new writes are never blocked.