From Turso

Turso and Databasezy both run libSQL, so a Turso database moves as a SQL dump replayed into a Databasezy libSQL instance.

Turso migration at a glance, from the migration source catalogue

Status	Available
Target engines	libSQL / SQLite
How we read it	Connection string, File upload
Continuous sync	No, copy only
Provider preset	turso

Before you start

• A Databasezy libSQL instance, or use --create.
• The Turso CLI, logged in to the organization that owns the database.

Find the connection string

Get the database URL with turso db show <db> --url and create a read-only token with turso db tokens create <db> --read-only. Put the token in the URL as authToken.

Turso notes

• Export with turso db shell .dump or download the database file, then upload it.

The preset rewrites libsql:// to https:// and flags a missing authToken (turso.auth_token). If you prefer not to give Databasezy network access to Turso, export a file instead:

shell

turso db shell my-db .dump > my-db.sql
zb migrate --from ./my-db.sql --engine libsql --create

Databases in a Turso group map to one Databasezy instance each; script the loop with --json.

Migrate

Portal

1. Open the target libSQL / SQLite instance (create one first if you need to) and choose the Migrate in tab.
2. Under Source, pick Connection string and paste the URL. The host is recognised as Turso; you can also pick it from the provider list.
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.

CLI

shell

# Dry run: print the preflight checklist and the plan, change nothing
zb migrate --from "libsql://my-db-org.turso.io?authToken=<token>" --to inst_abc --dry-run

# Start it (or use --create --size s1 instead of --to to create the target)
zb migrate --from "libsql://my-db-org.turso.io?authToken=<token>" --to inst_abc

zb migrate status mig_123

API

shell

curl -sS https://api.databasezy.com/v1/orgs/$ZB_ORG/instances/inst_abc/migrations \
  -H "Authorization: Bearer $ZB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "source": {
    "kind": "connection_string",
    "url": "libsql://my-db-org.turso.io?authToken=<token>",
    "provider": "turso"
  },
  "mode": "copy"
}'

# Follow progress, preflight report and verification
curl -sS https://api.databasezy.com/v1/orgs/$ZB_ORG/instances/inst_abc/migrations/mig_123 -H "Authorization: Bearer $ZB_API_KEY"

Then reveal the new instance’s auth token and change the client:

before and after

// createClient({ url: "libsql://my-db-org.turso.io", authToken: TURSO_TOKEN })
createClient({ url: "libsql://libsql-7f3k.us-east.databasezy.com", authToken: ZB_TOKEN })

Verify

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.

Cutover

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.

Roll back

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.

Troubleshooting

Preflight reports turso.auth_token

The URL has no authToken. Create a read-only token and add it to the URL.

Preflight cannot connect to the source

Check that the source accepts connections from the egress addresses preflight prints, that the host is the public one and that the password has not been rotated. zb migrate --dry-run shows the exact URL that will be used after any rewrites.

Preflight lists blocking items

Each item has a machine code and a fix. Nothing is written to the target until every blocking item is resolved; warnings do not block.

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