The query hit. The table needed more. You open the migration file and type: ALTER TABLE users ADD COLUMN last_login TIMESTAMP; The command is small. The change is not.
A new column changes the structure of your data. It adds capability. It enforces clarity. It can break production if handled without care.
When you add a column, think scope first. Will it be nullable? Should it have a default? Will existing queries fail? In PostgreSQL, adding a column is fast for small datasets but can lock the table on write. In MySQL, the cost depends on storage engine and column type. SQLite rebuilds the table. Know your database before you commit.
Naming matters. A new column name should be short, descriptive, and follow your schema’s pattern. Avoid names that require decoding. last_login is clear. ll_dt is noise.
Data type defines limits. Integers and IDs fit small, controlled values. Text columns can carry wide variance but expand indexes. Timestamps grant order. JSON columns allow flexibility but may hide structure from queries. Choose types that match the use case, not the temptation of “future proof.”