The migrations pane

Reads from: your Worker’s manifest and its health keys.

What it shows

Migrations is what a migration is, rolling a schema change is the walkthrough, pithy migrate is what runs them, and shared databases is why one migration can span Workers.

What has run, and what is pending, per database.

A migration ledger is a list of applied names, and a pending one is a name the registry has that the database does not.

Running one is not a button here

pithy migrate is the command, and that is deliberate rather than an omission.

A migration is a schema change against production data. It belongs in the same place your other deploy steps are — a terminal, or CI — where it is reviewed, versioned and repeatable.

What the CLI does that a pane could not

It runs every visited database’s whole registry.

--worker narrows what is reported and which databases are visited. It never narrows the registry a visited database runs — because a shared database’s ledger holds both Workers’ migrations, and a partial provider reads as corrupted state.

The ordering is stable forever

A released migration is never renumbered and never edited.

A change to a migration that has run somewhere is a change that will not run there — the ledger records applied migrations by name, so removing a name a real database has recorded is a corrupted chain.

History is not edited.

The ownership stamp

A database carries one, so a second project pointed at somebody else’s database is caught rather than migrated into.

An unstamped database is adopted on first migrate; your own is a no-op.

Every migration has a tested down

Which is what makes a rollback a plan rather than a hope.

Where a pending migration shows up elsewhere

pithy doctor reports it and names the command.

pithy deploy refuses rather than shipping a Worker whose code expects a column that is not there.

Local and remote are the same run

The registry, the ordering and the per-database runs are identical everywhere.

Only the driver differs — locally through Miniflare against the same store wrangler dev reads, remotely over the D1 API. You pass no ids.

ESC