Skip to content

From Cloudflare D1

Tested with: zb migrate 0.1 --from d1: (wrangler command line unit-tested) · generic upload flow

D1 is SQLite, so a D1 database moves to a Databasezy libSQL instance as a SQL export.

Cloudflare D1 migration at a glance, from the migration source catalogue
Status Coming soon · phase 2
Target engines libSQL / SQLite
How we read it File upload
Continuous sync No, copy only
Provider preset None yet (generic)
  • A Databasezy libSQL instance, or use --create.
  • Wrangler installed (npm install -g wrangler) and logged in (wrangler login) to the Cloudflare account that owns the database. wrangler d1 list shows the database name.
  • A short write freeze while you export.

There is no connection string to copy: D1 is reached through Workers bindings and Wrangler. Pass the database name as --from d1:<database> and zb runs wrangler d1 export <database> --remote --output <tmp>/d1-<database>.sql, then uploads the SQL into a libSQL instance. If wrangler is not installed, zb stops (exit code 6) and prints the install command and the manual export, npx wrangler d1 export <database> --remote --output=<database>.sql, whose file you upload with zb migrate --from ./<database>.sql --engine libsql.

  • Run zb migrate --from d1:<db> --create, which runs wrangler d1 export <db> --remote and uploads the SQL.
  • Or export with wrangler d1 export <db> --remote --output=dump.sql and upload the file.

Workers cannot open TCP connections to most databases; libSQL is reached over HTTPS, so the @libsql/client package works from a Worker. See the Cloudflare Workers guide.

  1. Open the target libSQL / SQLite instance (create one first if you need to) and choose the Migrate in tab.
  2. Under Source, pick Upload a dump and drop the file. The format is detected from the file name.
  3. Run Preflight and work through the checklist. Blocking items must be fixed before the copy starts.
  4. Start the copy and follow Copy and Verify. Mismatches are listed per table or collection.
  5. Point your application at the new instance. The Report step keeps the timings and verification results.

Verification compares row counts per table. Run a few of your application’s queries against the new instance with a libSQL client before you switch traffic.

This source is copy only. Writes that reach the source after the copy starts are not carried over, so for a database that changes, stop writes before you start the copy (maintenance mode, or scale writers to zero), run the migration, check verification, then point the application at the Databasezy connection string.

A migration never deletes anything on the source. Until you decommission it, rolling back means pointing the application back at the source. Writes made on Databasezy after you switched are not on the source; if you need them, copy them back before switching. Cancel a running migration with zb migrate cancel <mig_id>; partially restored data stays on the target, so restart with --drop-target or delete the instance.

Install it with npm install -g wrangler and run wrangler login, or run the printed npx wrangler d1 export ... command and upload the file with zb migrate --from ./<database>.sql --engine libsql.

Check wrangler whoami (logged in to the right account) and that the name after d1: is listed by wrangler d1 list.

Cloudflare’s export does not handle virtual tables such as FTS5 indexes. Drop them before exporting and recreate them on the new instance.

For anything else, zb migrate status <mig_id> shows the failing step and its message. How migrations work describes every step.