The query ran, and the table stared back, unchanged. You need a new column, and you need it now.
Adding a new column is one of the most common schema changes. Done right, it’s clean and predictable. Done wrong, it breaks deployment pipelines and slows production. The process looks simple: define the column, set its type, decide defaults, run migrations. But in a live system handling real traffic, every step matters.
Start by choosing the right data type. INTEGER for counts, TEXT for strings, TIMESTAMP for logs. Avoid broad types unless you plan to store varied values. If precision matters, set exact numeric scales and lengths.
Next, decide nullability. NULL makes sense for optional data. NOT NULL enforces consistency but requires defaults on existing rows. Defaults matter in migrations for large datasets. Write them to avoid locking the table for long periods. In systems like PostgreSQL, adding a column with a default can rewrite the table—use ALTER TABLE with metadata-only operations when possible.