Revision 1 — the current text. The evidence on this page is this revision’s own — it has not been carried forward from, or to, any other revision.
Covers schema.ts drifting ahead of the generated migrations, and a migration that exists but was applied to only one of D1's local/remote targets. Does not cover Drizzle Studio or Drizzle Kit connection errors (a different failure mode with different messages), and does not cover the equivalent D1_ERROR: no such table thrown outside of Drizzle — see the general D1 migration-not-applied playbook for that.
Unverifiedno reproductions yetWhy this confidence?8 steps, exactly as this revision published them.
A query built from a Drizzle schema fails because the underlying D1 database doesn't actually have the column or table the schema.ts model describes.
What happens next
Confirm drizzle-kit generate was run after the schema.ts change that added this column/table — editing schema.ts alone does not touch the database; Drizzle only produces SQL when you explicitly generate a migration from the diff.
grep -rl "<column_or_table_name>" drizzle/*.sqlExpected result
No migration file mentions the column/table — schema.ts and the migrations folder have drifted apart.What happens next
Generate a migration from the current schema.ts, then apply it to the target that's failing.
Changes system or service state. Review before running.
Creates a new .sql migration reflecting the current schema.ts and applies it to the remote D1 database, adding the missing column/table. Existing rows keep their data; only the schema changes.
npx drizzle-kit generate
npx wrangler d1 migrations apply <DATABASE_NAME> --remoteWhat happens next
D1 keeps separate local and remote databases, and each needs its own wrangler d1 migrations apply run. A migration generated and applied locally during development is not automatically applied to the remote database used in production, or vice versa.
npx wrangler d1 migrations list <DATABASE_NAME> --remoteExpected result
The migration that adds the column/table is listed as not yet applied for this target.What happens next
Check the table schema directly against the target that was failing, then repeat the Drizzle query that threw.
npx wrangler d1 execute <DATABASE_NAME> --remote --command "PRAGMA table_info(orders);"Expected result
The column/table is listed, and the Drizzle query that previously threw now returns normally.What happens next
Run migrations apply against whichever target (local or remote) is missing it — run both if both need it, since they're independent.
Changes system or service state. Review before running.
Applies any migrations D1 hasn't recorded yet, separately for each target given. Already-applied migrations and existing data are untouched.
npx wrangler d1 migrations apply <DATABASE_NAME> --local
npx wrangler d1 migrations apply <DATABASE_NAME> --remoteWhat happens next
Check that migrations_pattern/migrations_dir in your Wrangler configuration actually match where drizzle-kit writes its output. A mismatch means wrangler d1 migrations apply silently finds nothing new to apply, even though drizzle-kit did generate a file — this is common when Drizzle's default output layout doesn't match wrangler's default migrations/*.sql glob.
The database schema now matches schema.ts on the target that was failing.
What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.
This counts only what was recorded against revision 1 itself. Nothing reported against another revision is included here — see the revision history for why.