Skip to content
Databasezy

Menu

Start free Log in
← All migration sources

Migrate from Turso

Guided today

Move libSQL / SQLite from Turso into a Databasezy instance. Plan a short maintenance window for the final copy and switch.

Moves into

Start a migration Turso migration guide

What moves

libSQL / SQLite

  • Tables, indexes, views and triggers from the SQLite file or dump
  • Row data, byte for byte

Preflight checklist

The preflight checks these for you and shows the result before anything is copied. Knowing them up front saves a round trip.

Specific to Turso

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

For every source

  • Allow the migration egress addresses shown in the portal through any firewall or IP allow-list.
  • Use a connection with TLS. The preflight reports if it cannot verify the source certificate.
  • Files upload straight to object storage through a pre-signed URL, in parts for large dumps.
  • Pick a target engine version at least as new as the source.
  • Check that the target size has room for the estimate, plus indexes rebuilt during restore.

Step by step

  1. Find the connection string in Turso

    Open the database in the Turso dashboard and copy its connection string. Use a user that can read every table you want to move.

  2. Run the preflight

    Start a migration from the Migrate in tab of the target instance, or from the CLI. The preflight connects, detects the engine and version, and checks for anything that will not carry over.

    Terminal
    zb migrate --from "libsql://<database>.<host>?authToken=<token>" --to inst_abc

  3. Review the estimate

    The preflight reports size, the target size and storage it recommends, and how long the copy should take. Pass --create to the CLI to provision a target sized from it.

  4. Copy

    Engine-native tools copy the data inside your target's cell. Progress shows per table, collection or key count in the portal and the CLI.

  5. Verify

    Row counts, sampled checksums, schema, sequences and indexes are compared. Any mismatch is listed in the result before you switch.

  6. Switch during a short maintenance window

    Without continuous sync, writes made after the copy starts are not carried over. Rehearse once to time the copy, then stop writes, run the final copy and verify, and switch your app's connection string.

How the pipeline runs for this source

  1. Step 1: Preflight

    Connects, detects the engine and version, estimates size and duration, and lists anything we cannot carry over.

  2. Step 2: Copy

    Runs the engine's own dump and restore tools inside your target's cell, with live progress per table or collection.

  3. Step 3: Verify

    Compares row counts, sampled checksums, schema, sequences, indexes and extensions. Mismatches are listed, not hidden.

  4. Step 4: Sync

    Optional for Postgres and MySQL: replication keeps the copy current while your app still writes to the source.

    Not available for this source

  5. Step 5: Cut over

    You point your app at the new connection string. With sync running, the switch takes seconds.

  6. Step 6: Report

    Durations, sizes, verification results and skipped objects, saved to the audit log and emailed to you.

Sync and access

Not available from Turso

Migrations from this source are one-time copies. Writes made after the copy starts are not carried over, so stop writes, run the final copy and verify, then switch. A rehearsal run tells you how long that takes.

Ways to read the source

Connection string (default)
A migration job in your target's cell connects out to the source over TLS.
File upload
Upload a dump file from the portal or the CLI; it goes straight to object storage.

With the CLI

Every method has a zb migrate form. Replace the placeholders with your own values.

From a connection string
zb migrate --from "libsql://<database>.<host>?authToken=<token>" --to inst_abc
From a file
zb migrate --from ./app.sqlite --engine libsql --create
Follow progress
zb migrate status mig_123

Further reading

Related sources: SQLite and edge

Questions

Does the migration change my source database?

A copy only reads. Continuous sync is different: it needs replication enabled on the source and adds a publication or replication user there. The guide lists exactly what is added and how to remove it.

What happens to the credentials I give you?

Source credentials are kept only as a Secret in the cell that runs the copy. The Secret is deleted when the migration finishes, or after 24 hours at the latest. Our control plane does not store them.

How much downtime should I plan for?

Turso does not offer continuous sync to us, so plan a window long enough for one copy and verify. Rehearse first; the preflight estimate and the rehearsal tell you how long it takes.

Which plans include continuous sync?

Continuous sync for Postgres and MySQL is part of the Solo plan and above, and arrives in rollout phase 2.

What if verification finds a difference?

The result lists each table or collection that does not match. Nothing is switched for you: you decide whether to re-run the copy, fix the source, or carry on.

Can I move a database onto secure hosting this way?

Yes, once instance-to-instance copies ship (coming soon). They cover engine upgrades, region moves and moving a database from shared to secure hosting, which needs a signed BAA for your organization.

Move off Turso

Start with a preflight. Before any data is copied, it tells you what will move, how big the target should be and how long the copy takes.

Start a migration Turso migration guide