Skip to content
Databasezy

Migrations

Bring your database over without guessing

Point the CLI at a connection string or a dump file. Preflight checks run first, the copy is verified table by table, and PostgreSQL and MySQL stay in sync until you choose the moment to cut over.

Migrations, step by step

  1. Step 01

    Preflight

    Engine version, size, extensions and replication settings are checked from the connection string before anything is written. Blocking items stop the run.

  2. Step 02

    Copy

    The engine's own tools (pg_dump, mysqldump, DUMP/RESTORE, mongodump) run as a job inside the target instance's namespace.

  3. Step 03

    Verify

    Row counts, sequence values, index counts and a schema hash are compared between source and target. A short count fails the migration.

  4. Step 04

    Sync and cut over

    PostgreSQL and MySQL sources keep replicating. When lag stays under 5 seconds you stop writes and run the cutover, which reports the measured downtime.

What you get

  • Provider-aware preflight

    Guided presets for Neon, Supabase, PlanetScale, Upstash Redis, Turso and MongoDB Atlas know each provider's quirks, such as pooler endpoints and TLS modes. Any other reachable connection string works too.

  • Continuous sync

    PostgreSQL uses logical replication and MySQL uses GTID replication on a dedicated channel, starting exactly where the copy ended.

  • Verified, not assumed

    Every migration ends with a report: durations, sizes, verification results, sync lag and the cutover downtime.

  • Files and local servers

    Upload .sql, .dump, .rdb, .sqlite and more, or dump a server on your machine with --from local. Nothing connects back to your laptop.

  • Source credentials stay short-lived

    They live in a Secret in the target's namespace and are deleted when the migration ends or after 24 hours. The control plane never touches the data.

  • Reverse sync for rollback

    For PostgreSQL, --reverse-sync replicates the new instance back to the old one after cutover so you can roll back.

Try it

A dry run prints the plan and the preflight checklist without starting anything.

shell
# Check first: plan and preflight only
zb migrate --from "postgres://app@old-host:5432/app" --create --name app-db \
  --mode copy_and_sync --dry-run

# Copy, verify and keep in sync
zb migrate --from "postgres://app@old-host:5432/app" --create --name app-db \
  --mode copy_and_sync

zb migrate status mig_01J9...
zb migrate cutover mig_01J9...   # after you stop writes to the source

Plan availability

Generated from the same plan catalogue that billing and the API use.

  • Free

    $0 /mo
    Included

    Copy, verify and continuous sync

  • Solo

    $25 /mo
    Included

    Copy, verify and continuous sync

  • Team

    $599 /mo
    Included

    Copy, verify and continuous sync

  • Enterprise

    Custom
    Included

    Copy, verify and continuous sync

Migrations are not plan-gated. The target instance follows your plan's size and storage limits.

Compare every plan on the pricing page

Questions

How long is my application down?

With continuous sync, only for the cutover: you stop writes, the last changes drain and sequences are copied. The cutover reports the measured downtime. A plain copy needs writes stopped for the whole copy.

What if the cutover cannot catch up?

If the target cannot apply the last writes within the timeout (120 seconds by default), the cutover is abandoned and sync keeps running. Nothing changes on either side.

Which engines support continuous sync?

PostgreSQL and MySQL connection-string sources. Other engines and file sources use a one-time copy followed by verification.

Where does my source need to allow connections from?

Preflight prints the cell's egress addresses and where to allow them for your provider, such as a security group or an IP access list.

Create your first database

A free instance, no card. Upgrade when you outgrow it; nothing converts silently.