# 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

```text
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