A new column in a database table can be harmless or catastrophic. Done well, it extends your schema without breaking existing queries. Done badly, it locks tables, crushes performance, and triggers rollback chaos. Every database—PostgreSQL, MySQL, SQLite—handles a new column differently. Precision matters.
Adding a new column starts with defining its type. Choose the smallest data type that meets the need. Avoid NULL defaults unless they make sense semantically. For high-throughput systems, add the column in a way that avoids full-table rewrites. In Postgres, adding a nullable column without a default runs in constant time. Adding a column with a default rewrites every row—plan for that.
In MySQL, an ALTER TABLE locks the table for the duration. For large datasets, use algorithms like INPLACE or tools like gh-ost to keep production online. In SQLite, schema changes copy the table under the hood—expect downtime for big tables.
Always check dependent code. ORMs may map models directly to table definitions, and missing migrations can silently drop columns in certain frameworks. Write migrations explicitly. Test them against a database snapshot of production scale.