From another Databasezy instance

An instance-to-instance migration copies one Databasezy instance into another in the same organization. It is the path for major version upgrades, moving regions and moving a database onto secure hosting.

Coming soon: phase 2

A guided Another Databasezy instance preset ships in rollout phase 2. Until then the steps below run as a generic migration: preflight checks the engine, version and size, but does not add Another Databasezy instance-specific checks or URL rewrites.

Another Databasezy instance migration at a glance, from the migration source catalogue

Status	Coming soon · phase 2
Target engines	PostgreSQL , MySQL , MariaDB , Valkey , Redis (compat) , libSQL / SQLite , DuckDB , MongoDB (Percona Server) , FerretDB (MongoDB-compatible) , ClickHouse , InfluxDB 3 , QuestDB , Meilisearch , Qdrant , Weaviate , CouchDB , TypeDB , TimescaleDB
How we read it	Instance to instance
Continuous sync	Yes, for PostgreSQL and MySQL
Provider preset	None yet (generic)

Before you start

• Both instances in the same organization, and permission to read the source and write the target.
• A target instance of the same engine family, created with the version, region, size or placement you want.

Find the connection string

There is no connection string: pass the source instance’s name or id. No egress allow-listing is needed.

Another Databasezy instance notes

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

• Major version upgrades: create the target on the new version and copy with sync. See engine version upgrades.
• Region moves: create the target in the new region. Data copied across regions counts as egress.
• Secure hosting: create the target with --placement secure (needs a signed BAA). To move an existing instance instead and keep its host name, change its placement in the portal or with PATCH /v1/orgs/{org}/instances/{id} and {"placement": "secure"}. See Secure hosting and the BAA.

Migrate

Portal

1. Open the target PostgreSQL instance (create one first if you need to) and choose the Migrate in tab.
2. Under Source, pick Another Databasezy instance and choose the source instance from your organization.
3. Choose Copy and sync to keep the target current until cutover, or Copy for a one-off copy.
4. Run Preflight and work through the checklist. Blocking items must be fixed before the copy starts.
5. Start the copy and follow Copy and Verify. Mismatches are listed per table or collection.
6. When the sync lag is low, stop writes and choose Cut over. The Report step keeps the timings and verification results.

CLI

shell

# New target: a newer major in the same region (or another region, or --placement secure)
zb instances create --engine postgres --engine-version 17 --size m2 --region us-east --name pg-prod-17 --wait

zb migrate --from pg-prod --to pg-prod-17 --mode copy_and_sync --dry-run
zb migrate --from pg-prod --to pg-prod-17 --mode copy_and_sync
zb migrate status mig_123
zb migrate cutover 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": "zerobase",
    "instance_id": "pg-prod"
  },
  "mode": "copy_and_sync"
}'

# 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"

# Cut over once the status is ready_for_cutover
curl -sS -X POST https://api.databasezy.com/v1/orgs/$ZB_ORG/instances/inst_abc/migrations/mig_123/actions/cutover -H "Authorization: Bearer $ZB_API_KEY"

Verify

Verification compares what the engine exposes: row counts per table for SQL engines, document counts per collection for document engines, key counts for key-value engines. Mismatches are listed in zb migrate status <mig_id> and the Verify step. Run your application’s tests against the new instance before you switch traffic.

Continuous sync and cutover

With copy and sync, the target keeps receiving changes after the copy. When zb migrate status reports ready_for_cutover (two lag samples in a row under 5 seconds):

1. Stop writes to the source: maintenance mode, scale writers to zero, or revoke the application user.
2. Run zb migrate cutover <mig_id> (or Cut over in the portal). The agent drains the last changes, copies sequence values (PostgreSQL), verifies again and stops replication. If the target cannot catch up in time, the cutover is abandoned and sync keeps running; nothing changes on either side.
3. Point the application at the Databasezy connection string and resume writes. zb migrate status shows the measured downtime.

Schema changes are not replicated, so freeze migrations between the copy and cutover. Details: what happens at cutover.

Sync applies to PostgreSQL and MySQL targets only; other engines from this source are copy only.

Roll back

A migration never deletes anything on the source. Until you decommission it, rolling back means pointing the application back at the source.

• Before cutover: cancel with zb migrate cancel <mig_id>. The publication, replication slot or replication channel the migration created is removed.
• After cutover: writes made on Databasezy are not on the source. For PostgreSQL, start the migration with --reverse-sync so the old database keeps receiving them after cutover and stays a valid fallback. Without it, copy the new data back with a migration in the other direction before you switch.

Troubleshooting

The target refuses the copy

The engines are not compatible. Instance-to-instance copies stay within an engine family; see engine conversions for the supported pairs.

The restore stops on an extension

The source uses an extension Databasezy does not ship. Drop it on the source if it is unused, or exclude the objects that depend on it with --exclude.

Sync is blocked with pg.wal_level or pg.replica_identity

Logical replication needs wal_level=logical on the source and a primary key (or REPLICA IDENTITY FULL) on every published table. Preflight lists the tables.

Sync is blocked on binlog or GTID settings

Continuous sync needs binlog_format=ROW, gtid_mode=ON, enforce_gtid_consistency=ON and a user with REPLICATION SLAVE and REPLICATION CLIENT. Preflight names whichever is missing.

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