The query returned fast, but the new column wasn’t there.
Adding a new column should be simple. In reality, the shape of the task depends on your database engine, schema size, indexing strategy, and uptime requirements. For small tables, an ALTER TABLE ... ADD COLUMN runs almost instantly. For large production datasets, adding a column can lock tables, trigger full table rewrites, and create downtime.
In PostgreSQL, a new column with a NULL default is metadata-only and completes quickly. But adding a column with a non-null default rewrites the table. In MySQL, even adding a nullable column can cause a full table rebuild depending on the storage engine and configuration. Understanding these differences is key to avoiding performance hits.
In schema migrations, the safest path is to break the change into steps. First, add the new column with a NULL default. Then backfill in small batches. Finally, apply constraints or defaults. This reduces lock time and risk. When paired with a feature flag system, you can control usage without exposing the column prematurely.