Adding a new column is one of the most common schema changes, but it’s also one of the easiest ways to hurt performance or cause downtime if done carelessly. On small tables, it feels instant. On large production datasets, it can lock writes, block reads, or trigger hours of migration work. The key is knowing how your database engine handles ALTER TABLE under the hood.
In MySQL and MariaDB, older storage engines rewrite the entire table when you add a column. That means heavy I/O and long locks. Newer versions support instant or in-place additions, but only under specific conditions—for example, appending a nullable column without default values. In PostgreSQL, adding a column with a default value rewrites the whole table unless you make it nullable first, then update in batches. SQLite rewrites the file for almost every schema change. Knowing these behaviors before you run a migration protects uptime.
The way you define the new column matters. Data type selection isn’t just about storing the right kind of data—it affects disk usage, index size, and query performance. Adding indexes during the same migration can compound the cost, so defer indexing until after the column exists and contains data.