workerd: D1 database binding failed with "no such table"

Fix D1 database binding failed with "no such table"

TL;DR

Your migrations were applied to one database (local or remote) but the worker is talking to the other. Run wrangler d1 migrations apply against the same target your worker uses, and double-check the database_id in the binding. wrangler dev defaults to a local SQLite file while deploys talk to the remote D1, so schema drifts between them.

Verbatim error

workerd: D1 database binding failed with "no such table"

Steps

1. Run npx wrangler d1 list. Expected: your database appears with its database_id.
2. Compare that ID with the database_id in the [[d1_databases]] binding in wrangler.toml. Expected: they match exactly.
3. Apply migrations to remote: npx wrangler d1 migrations apply MY_DB --remote. Expected: the output lists the migrations it applied.
4. Apply migrations locally too: npx wrangler d1 migrations apply MY_DB --local. Expected: the local database file updates.
5. Verify tables on the failing target: npx wrangler d1 execute MY_DB --remote --command "SELECT name FROM sqlite_master WHERE type='table'". Expected: your tables are listed.
6. Redeploy (or restart dev) and retry the query path. Expected: no "no such table" error.

Use this when

• D1 throws "no such table" in production but tables exist locally, or vice versa
• The database_id changed after recreating the database
• The migrations folder grew but was never applied with --remote

Not for this skill when

• The database binding itself is missing from the config
• The query has a syntax error (fix the SQL)
• You need to export or import D1 data (different workflow)

Variant phrasings

• d1 no such table after deploy
• wrangler d1 migrations not applied
• sqlite error no such table d1 remote
• D1 table missing production

Why it happens

wrangler dev defaults to a local SQLite file while deployed workers talk to the remote D1 instance. migrations apply targets only one of them unless you run it twice with --local and --remote, so it is easy to end up with schema in one place and an empty database in the other.

Edge cases

• Running --remote against the wrong database_id silently migrates the wrong database; verify the ID first.
• Preview environments need their own migration run against their database.
• Very large seed files can hit the batch size limit; split them into smaller migrations.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jj3EG391HYTsaqcPBLSa8Q