The schema needs a new column. The migration runs in minutes, but the decision lasts for years.
Adding a new column is one of the most common changes in database design, yet it is also one of the most dangerous if done carelessly. Every new column changes the contract between your application and the database. It adds surface area for queries, indexes, constraints, and potential bugs.
Start with the name. Keep it exact. Avoid vague terms or abbreviations that will force future readers to check the codebase or documentation just to understand the data. A well-named column saves hours across the lifetime of a system.
Choose the data type for both today and tomorrow. An integer can become a bigint, but migrations on large tables under load can cripple performance. A text field can store JSON, but then you are trading structure for flexibility — and paying the price with slower queries and harder validations.
Decide if the new column allows NULL. If it should never be NULL, enforce that rule from the start. Adding a NOT NULL constraint to a populated table is harder than setting one at creation.