The table groaned under the weight of old data. You open it, scan the schema, and know in an instant: it needs a new column.
Adding a new column is rarely just a schema tweak. It is a change that touches queries, models, indexes, migrations, tests, and sometimes entire systems. The goal is to do it fast, safely, and without data loss. That starts with choosing the right data type. Memory use, query performance, and future-proofing all hinge on this decision. For example, using INT where BIGINT is needed will force a painful change later.
Name the new column with clarity. Avoid abbreviations that make sense today but will confuse the next engineer reading the code. Keep to naming conventions in your codebase and database. Consistency now avoids refactors later.
If you are working on a live system, migrations must be reversible. Use ALTER TABLE commands with zero-downtime techniques where possible. PostgreSQL and MySQL each have their own quirks: PostgreSQL can add a column with a default value without rewriting the table in recent versions; MySQL may require temporary locks depending on the storage engine. Benchmark on staging before touching production.