Minimal-downtime migration: initial load, then CDC

  • Schema converted
  • Validated
  • Resumable
  • Parallel writes
Start Migration Evaluation Load Mode Docs

Start a stream. Watch rows move.

PostgreSQL → MySQL · 16 tables · live rows, rates, and per-table progress

Cross-database migration moves schema and data from one engine to another — for example, MySQL to PostgreSQL — without manual DDL, without lossy intermediate exports, and without staging tables. The hard part is rarely reading rows; it is converting types correctly, recreating indexes and foreign keys in a safe order, and recovering when a load stops mid-copy.

DBConvert Streams handles those parts in one stream: schema is converted automatically with visible type mappings, eligible loads are split into primary-key ranges with saved progress, and every load is checked at both ends: before it starts, you see what will happen to each target table; after it finishes, totals and rows are compared with the source, and the rows that differ open side by side with their source values in Compare.

Migrates from

Databases, files, and object storage, self-hosted or managed.

  • MySQLMySQL
  • MariaDBMariaDB
  • PerconaPercona
  • PostgreSQLPostgreSQL
  • Amazon RDSAmazon RDS
  • AWS AuroraAWS Aurora
  • Google Cloud SQLGoogle Cloud SQL
  • Azure DatabaseAzure Database
  • NeonNeon
  • SupabaseSupabase
  • Databricks LakebaseDatabricks Lakebase
  • YugabyteDBYugabyteDB
  • DigitalOceanDigitalOcean
  • S3 / MinIOS3 / MinIO
  • Local filesLocal files

Migrates to

Any PostgreSQL or MySQL-compatible database, plus files and object storage.

  • MySQLMySQL
  • MariaDBMariaDB
  • PerconaPercona
  • PostgreSQLPostgreSQL
  • Amazon RDSAmazon RDS
  • AWS AuroraAWS Aurora
  • Google Cloud SQLGoogle Cloud SQL
  • Azure DatabaseAzure Database
  • NeonNeon
  • SupabaseSupabase
  • Databricks LakebaseDatabricks Lakebase
  • YugabyteDBYugabyteDB
  • DigitalOceanDigitalOcean
  • S3 / MinIOS3 / MinIO
  • Local filesLocal files
  • SnowflakeSnowflake

Schema is converted automatically between MySQL and PostgreSQL; see CDC replication to keep the target current after the load. Migrating from Oracle or SQL Server is covered by the DBConvert desktop tools instead.

Measured Performance

Load Throughput You Can Measure

Real numbers from local migration tests.

25M rows

in 48 seconds

260M rows

49 GB in 8 minutes 18 seconds

101 MB/s

steady from 25M to 260M rows

8 min 56 s

the same 49 GB into Snowflake

MySQL → PostgreSQL local benchmark, end to end, on a single desktop machine. Performance depends on hardware, row size, and database configuration.

Finished load run: 260,000,000 rows and 49.13 GB of big_products moved from MySQL to PostgreSQL in 8m18s, reader and writer averaging 101 MB/s

The 260-million-row run: one table, 49.13 GB, finished in 8 minutes 18 seconds.

MySQL to Snowflake load: 260,000,000 rows and 49.13 GB in 8m56s, with a breakdown of export 588 ms, upload 10.35 s and copy into 2.18 minutes

The same table into Snowflake: 49.13 GB in 8 minutes 56 seconds, end to end, including the upload and Snowflake's COPY INTO.

Scope

Flexible Migration Scope

More than standard table-to-table migration.

Example

Join a CSV and a production MySQL table, then migrate the result into PostgreSQL — without staging tables. Powered by Cross-database SQL.

Cross-Database SQL in Action

Cross-database SQL query joining MySQL and PostgreSQL tables as migration source
Schema

Automatic Schema Conversion & Built-In Validation

No manual DDL rewriting required.

Compare tab after Verify data: source and target side by side, narrowed to the differing rows, expected values marked blue, found values red, and a row missing from the target held in line by a hatched row

Supported Migration Paths

  • MySQL to PostgreSQL
  • PostgreSQL to MySQL
  • Database to files (CSV, JSON, Parquet)
  • Files to database (schema inferred automatically)
  • MySQL / PostgreSQL to Snowflake

Schema Conversion Handles

  • Automatic MySQL ↔ PostgreSQL type mapping (INT → BIGINT, JSON → JSONB, ENUM → VARCHAR, etc.)
  • Index and constraint recreation
  • Foreign keys recreated in dependency-safe order
  • Tables and column definitions
Workflow

Database Migration Workflow

1. Define source and scope

Select the source, pick tables or write a SQL query, and apply row filters.

2. Configure schema and write behavior

Choose a schema policy (fail if exists, validate existing, create missing only, or drop and recreate) and a write mode (fail if not empty, append, truncate and load, or upsert) independently for structure and data.

3. Review the plan and run

See which target tables will be created, reused, or dropped before anything is written; dropping tables takes a second confirmation. Data is then read and written in parallel through embedded JetStream.

4. Monitor progress

Open a run to track saved rows, chunks, throughput, and table status, then Verify data to compare the result with the source.

Resumable Load

Large loads continue from where they stopped

Eligible loads into MySQL or PostgreSQL targets are split into primary-key ranges. A compatible saved state can resume from the last completed chunk; an incompatible one is reset before a fresh load.

Stopped Load run showing saved progress, chunks, and the Reset action when saved state is no longer compatible

Open the stopped run to review saved rows, chunks, and table status. The config offers Resume Load only while that saved state remains compatible; otherwise Reset prepares a clean rerun.

Resumable Load docs
Verify data

Prove the target matches the source

Let an AI write the queries. The engine moves the data and proves it landed.

Verify data compares row counts, sums, ranges and text lengths for every table and names the columns that don't match. See them in Compare opens those rows side by side.

Verification result for a finished load: 84 rows differ, rows 500 to 498, the differing columns with their row counts, the totals of each column, and a See them in Compare button
  • Tables whose totals differ get a row-by-row comparison automatically
  • Turn on Verify data after run to check every load when it finishes
  • 20 million rows compared row by row in 72 seconds on a developer workstation
Review and Verify a Load docs

Common Use Cases

MySQL → PostgreSQL Modernization

Move a production MySQL database to PostgreSQL — schema conversion handled automatically.

On-Prem to Cloud Migration

Move self-hosted databases to cloud targets with a staged rollout and planned cutover.

Environment Seeding

Clone a production database subset into staging or dev for testing without affecting the primary.

Source Consolidation

Combine multiple databases and files into a single target database or storage destination.

Operational Exports

Export table or query results to CSV, JSONL, or Parquet in local storage or S3.

Related workflows

Before and after migration

Validate before cutover, build the source from multi-database SQL, or keep the target current after the load finishes.

Validate structure and data first

Inspect schemas, compare what landed, and review data before production migration windows.

Use SQL as the migration source

Build the source dataset from multiple databases, files, or S3-backed inputs before writing to the target.

Keep the target current after the load

Switch to CDC after the load finishes to keep the target current through cutover.

Run a migration test before the cutover window

Verify the converted target against the source, row by row, before you schedule the production move.

A Load pass covers the migration runs themselves: 30 days of clean Load for a one-time price.

Start Migration Evaluation View Pricing
Product Overview Load Mode Docs