Adding a new column to a database table is one of the simplest operations in concept and one of the most misunderstood in practice. At its core, it changes the shape of your schema. It tells the system that from now on, each record will carry more information. But the method, impact, and risk vary depending on the database engine, the amount of data, and the constraints in play.
In SQL, the basic form is clear:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This statement runs fast on small tables but can lock or block queries on large ones. In PostgreSQL, adding a nullable column with no default is instant. Adding a column with a default value rewrites the table. In MySQL, the storage engine matters. PostgreSQL 11 introduced optimized storage for certain defaulted columns. MySQL 8.0 reduced locking in some cases.
For distributed systems, a new column is not only a schema change but also a versioning challenge. Applications reading and writing the table must be able to handle both the schema before and after the change. This is why rolling out a new column in production often involves multiple deploy steps: