Engine conversions

Some engines share a wire protocol and a storage format, so a “conversion” is a migration with a different target engine. zb migrate --from inst_abc --to inst_def between two Databasezy instances is the fast path; from external sources, use --engine <target>.

From	To	How	Caveats
Redis 7.2 or older	Valkey	Key by key: SCAN, DUMP + PTTL, RESTORE ... REPLACE (RDB payloads, TTLs kept); .rdb uploads are loaded into a throw-away server and copied the same way	Redis 7.4+ payloads and module keys (JSON, Search) do not restore into Valkey; copy only
Valkey	Redis	Same key-by-key copy	Redis lacks Valkey 8 commands (HEXPIRE and friends)
MySQL 8.x	MariaDB 11.x	mysqldump (no GTID_PURGED, no column statistics) piped through a DDL rewrite: utf8mb4_0900_* to utf8mb4_uca1400_*, MySQL-8-only /*!80xxx */ clauses neutralised, DEFINERs stripped	JSON becomes LONGTEXT with json_valid(); functional indexes fail; copy only
MariaDB	MariaDB / MySQL	mysqldump with MariaDB-safe flags (--loose-column-statistics=0, --loose-set-gtid-purged=OFF)	MariaDB-only syntax (sequences, system-versioned tables) does not load into MySQL
SQLite file	libSQL	sqlite3 .dump, then libSQL HTTP batches	Checkpoint the WAL before upload; virtual tables (FTS5, R*Tree) are recreated by hand
libSQL	SQLite file	Read the tables out with a libSQL client; there is no one-step file export yet	—
MongoDB (Atlas, self-hosted)	FerretDB	mongodump --archive | mongorestore --archive	Transactions, $text, GridFS, change streams; unsupported index options are reported
FerretDB	MongoDB	mongodump --archive | mongorestore --archive	—
PostgreSQL	TimescaleDB	pg_dump -Fc | pg_restore between timescaledb_pre_restore() and timescaledb_post_restore(); tables stay regular tables	Convert large tables with create_hypertable(..., migrate_data => true) after the copy; see TimescaleDB
PostgreSQL / any SQL	DuckDB	Export tables to CSV (or a .duckdb file) and upload	Analytical copy, not a live migration; see DuckDB

Per-engine details for every engine are under migrating by engine.

Engine version upgrades

Minor and patch upgrades are automatic in the maintenance window, always preceded by a backup. Major upgrades are a migration between two instances so you can test first:

shell

zb instances create --engine postgres --engine-version 17 --size m2 --region us-east --name pg-prod-17
zb migrate --from pg-prod --to pg-prod-17 --mode copy_and_sync     # logical replication across majors
zb migrate cutover mig_123

In-place major upgrades are planned for operator-backed engines. Until an engine has one, PATCH /v1/orgs/{org}/instances/{id} refuses that engine_version with the reason, and GET …/instances/{id}/options and the portal’s Settings → Version list which versions an instance can be upgraded to in place.

What never converts

Postgres to MySQL and back, or any conversion that changes the SQL dialect, is out of scope for zb migrate; use a schema-aware tool (pgloader, AWS DMS) and then migrate the result.