Skip to content
Databasezy

Menu

Start free Log in
← All migration sources

Migrate from another Databasezy instance

Coming soon

Move PostgreSQL, MySQL, MariaDB and 15 more engines from another Databasezy instance into a Databasezy instance. For PostgreSQL and MySQL, continuous sync (coming soon) keeps the copy current so the switch takes seconds. The guided preset is coming soon; the generic pipeline is described below.

Moves into

Start a migration zb migrate CLI guide

What moves

PostgreSQL

  • Schemas, tables, indexes, constraints and views
  • Functions, triggers and sequences, with sequence values checked after the copy
  • Extensions we ship; any we do not are named in the preflight
  • Roles and grants are listed; new credentials are issued for the target

MySQL

  • Databases, tables, indexes and foreign keys
  • Views, stored procedures, functions and triggers
  • Users are listed; new credentials are issued for the target

MariaDB

  • Databases, tables, indexes and foreign keys
  • Views, stored procedures, functions and triggers
  • Users are listed; new credentials are issued for the target

Valkey

  • Every key in every logical database, with its TTL
  • Strings, hashes, lists, sets, sorted sets and streams
  • Lua scripts and module-backed keys are listed for you to review

Redis (compat)

  • Every key in every logical database, with its TTL
  • Strings, hashes, lists, sets, sorted sets and streams
  • Lua scripts and module-backed keys are listed for you to review

libSQL / SQLite

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

DuckDB

  • Tables, views, sequences and indexes from a .duckdb file or another DuckDB instance
  • CSV files loaded as tables, with column types detected

MongoDB (Percona Server)

  • Databases, collections and documents
  • Indexes, including unique and TTL indexes

FerretDB (MongoDB-compatible)

  • Databases, collections and documents
  • Indexes, including unique and TTL indexes
  • Queries or indexes FerretDB does not support are named in the preflight

ClickHouse

  • Tables recreated from SHOW CREATE TABLE; replicated and Cloud engines become MergeTree
  • Rows streamed table by table in ClickHouse Native format, then views

InfluxDB 3

  • Tables or measurements with their time-series data
  • Tags, fields and designated timestamps

QuestDB

  • Tables or measurements with their time-series data
  • Tags, fields and designated timestamps

Meilisearch

  • Indexes, documents and index settings
  • Ranking rules, synonyms and stop words where an equivalent exists

Qdrant

  • Collections, points and vectors
  • Payloads and payload indexes from snapshots

Weaviate

  • Collections, objects and vectors
  • Schema and module settings

CouchDB

  • Databases and documents
  • Design documents and views

TypeDB

  • Schema and data through TypeDB 3 database export and import

TimescaleDB

  • Schemas, tables, indexes, constraints and views
  • Functions, triggers and sequences, with sequence values checked after the copy
  • Extensions we ship; any we do not are named in the preflight
  • Hypertables and their chunks
  • Roles and grants are listed; new credentials are issued for the target

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 Another Databasezy instance

  • Used for engine version upgrades, region moves and moving a database onto secure hosting.

For every source

  • For continuous sync on Postgres, the source needs wal_level=logical. For MySQL, binlog_format=ROW and a replication user.
  • 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. Pick the source instance

    Choose the instance to copy from in the portal, or note its id for the CLI. Both instances must be in your organization.

  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 inst_abc --to inst_def

  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. Keep it in sync, then cut over

    Leave continuous sync running while you test against the new instance. When the lag shown in the portal is near zero, switch your app's connection string and run the cutover. It stops replication and resets sequences. Continuous sync and cutover are coming soon; until then, switch during a short maintenance window.

    Terminal
    zb migrate cutover mig_123

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.

  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

Supported for PostgreSQL and MySQL, coming soon

After the first copy, logical replication or binlog replication keeps the target current while your app still writes to Another Databasezy instance. You switch when the lag is near zero, then run the cutover. Continuous sync is part of the Solo plan and above.

MariaDB, Valkey, Redis (compat), libSQL / SQLite, DuckDB, MongoDB (Percona Server), FerretDB (MongoDB-compatible), ClickHouse, InfluxDB 3, QuestDB, Meilisearch, Qdrant, Weaviate, CouchDB, TypeDB, TimescaleDB: one-time copy only, so plan a short maintenance window.

Ways to read the source

Instance to instance
Copy between two of your instances, for upgrades, region moves or secure hosting.

With the CLI

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

Between two instances
zb migrate --from inst_abc --to inst_def
Follow progress
zb migrate status mig_123
zb migrate cutover mig_123

Further reading

Related sources: Anywhere else

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?

With continuous sync, seconds: the time to change your app's connection string. Without it, the time for one copy and verify. The preflight gives you an estimate before anything runs.

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.

Bring your database over

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 zb migrate CLI guide