Database migration bugs are easy to misread.
Types pass locally. The app builds. The PR looks normal. Then production starts throwing:
column does not existZairoo hit this once.
The Drizzle schema already had a new field, and production code started selecting it. But the production database had not actually run the matching migration. The result was not only a broken new feature. Some unrelated pages also failed.
Drizzle makes this class of problem more visible because many queries are generated from the schema. If the schema includes one column that does not exist in production, a full-row select can fail immediately.
When I looked back at it, the issue was not just “we forgot to run SQL.”
A Drizzle migration has several pieces that need to agree:
- the migration SQL exists
_journal.jsonrecords the migration- the snapshot exists
- the production database has actually applied it
If any one of those is missing, code and database can silently split.
After that incident, I started checking schema PRs differently. I do not only read the TypeScript schema or the SQL file. I check whether the whole migration chain is complete.
If production says column does not exist, I now suspect schema drift before touching business logic.
The lesson is simple: “the code looks right” does not mean the environment is true. This is especially true for databases.