A new column in a database sounds small. It is not. It changes the schema, the queries, the joins, the indexes, and the way data flows through your system. Every new column forces decisions about data type, nullability, default values, and constraints. Get these choices wrong, and you ship bugs into production.
In PostgreSQL, adding a new column is straightforward:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP WITH TIME ZONE;
But correctness is more than syntax. You must check the effect on read and write performance. You must ensure downstream services and analytics pipelines know about the change. When you add a new column to a large table, watch for locks. In some engines, this can halt writes until the DDL completes. For high-traffic systems, use operations that run concurrently or trigger background migrations.
Version control for database schema is mandatory. Migrations should be atomic, reversible, and reviewed like code. Tools like Flyway, Liquibase, or Prisma Migrate can help, but they do not replace careful planning. Always test schema changes against production-like data.