MySQL
PostgreSQL

MySQL to PostgreSQL Converter

Schema conversion, type mapping, and one-way or two-way synchronization between MySQL and on-prem or cloud PostgreSQL.

Version
4.4.2
Release Date
Sept. 2, 2026
Size
26.3 MB

Copy a MySQL database into PostgreSQL without writing the target schema by hand. DBConvert connects to both servers, proposes a PostgreSQL type for every column, and creates the tables, indexes, and foreign keys before it moves a row.

  • Reads MySQL, MariaDB, or Percona Server - on-prem, Amazon RDS / Aurora, Azure Database for MySQL, or Google Cloud SQL.
  • Writes to PostgreSQL on your own server, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.
  • Converts the database once, or keeps MySQL and PostgreSQL synchronized on a schedule - in one direction or both - while you cut over.
  • Runs on Windows as a desktop application; every job is saved with both connections and re-run on demand.
How it runs

A Windows application that talks to both servers

You install it, point it at a live MySQL server and a live PostgreSQL server, and it does the work in place.

Windows desktop

A native Windows application with a wizard, installed on your own machine. Your credentials and your data never pass through a third-party service.

Live connections, not files

Both ends are database connections. There is no SQL text box to paste into and no mysqldump file to upload - the tool reads the source server directly and writes to the target server.

Saved and repeatable

A job stores both connections, the table selection, and the options. Run it again from the interface, or start it by name from a batch file or Task Scheduler with --run-job.

Two modes, one download

Convert once, or keep MySQL and PostgreSQL connected

One download covers both. You choose the mode when you set up the job.

One-time conversion

Schema, indexes, foreign keys, and rows move in one pass with the type mapping you reviewed. Validate the counts, then point the application at PostgreSQL.

Repeat synchronization

Keep both databases in use while you cut over: run the job on a schedule, in one direction or in both, so changes made in MySQL reach PostgreSQL until the old server is retired.

Why move

When PostgreSQL is the right target

Stricter relational behavior

PostgreSQL is usually chosen when the application needs stronger constraints, richer SQL, and predictable transactional behavior rather than MySQL compatibility.

Richer native types

First-class jsonb, arrays, ranges, and user-defined types let a schema that pushed this logic into application code move more of it back into the database.

What needs attention

How DBConvert handles the MySQL → PostgreSQL differences

Every mapping below is a default you can review or override per table before the run.

In MySQL Why it does not carry over What DBConvert does
AUTO_INCREMENT PostgreSQL generates keys from a sequence rather than from a column attribute. The primary key is created as BIGSERIAL, so key generation moves to a PostgreSQL sequence that the table owns.
Unsigned integers PostgreSQL has no unsigned types, so the upper half of the range has nowhere to go. Each type widens to one that still holds the values: TINYINT UNSIGNED → SMALLINT, BIGINT UNSIGNED → NUMERIC(20).
TINYINT(1) MySQL uses the same declaration for a true boolean and for a small integer code, and only your data says which it is. Converted to boolean automatically. Override it to smallint in the review when the column stores codes rather than 0/1.
ENUM and SET MySQL declares both inline on the column; PostgreSQL enum types are separate objects and it has no equivalent of SET at all. The values come across as text - ENUM becomes VARCHAR and SET becomes TEXT. A native PostgreSQL enum type is not created for you.
TIME A MySQL TIME is a signed duration that can run past 24 hours; a PostgreSQL time is a clock reading and cannot. Converted to interval, which keeps durations that a clock type would reject.
Identifier names PostgreSQL folds unquoted names to lower case and stops at 63 bytes, so mixed-case or long MySQL names do not arrive unchanged. Every destination name is an editable field in the review, and the header counts how many you have renamed before the run.
JSON, DATETIME, YEAR The names exist on both sides but do not always mean the same thing. JSON arrives as PostgreSQL json, DATETIME and TIMESTAMP both become timestamp, and YEAR - which PostgreSQL does not have - becomes smallint.

Procedural code stays behind

The migration covers tables - their fields, types, defaults, and indexes - and the foreign keys between them. MySQL stored procedures, functions, and triggers stay in the source and are rewritten by hand in PL/pgSQL: MySQL's procedural syntax (DELIMITER, SIGNAL, MySQL-specific error handling) has no direct PL/pgSQL equivalent. On most schemas this is a small share of the work, and it is rewrite work on any route.

You see every column before a row moves

The review lists all 25 columns of this table with the PostgreSQL type each one will get, and every name and type is editable. The decisions worth checking are visible here: the key becomes BIGSERIAL, BIGINT UNSIGNED widens to NUMERIC(20), TINYINT(1) becomes BOOLEAN, ENUM and SET land as VARCHAR and TEXT, and TIME becomes INTERVAL.

DBConvert type-mapping review for a MySQL to PostgreSQL conversion, listing 25 columns with the PostgreSQL type each will get

If you need continuous replication instead

Scheduled synchronization is enough for a staged cut-over that runs for days or weeks. When the source has to stay live and every change must land within seconds, that is log-based change data capture, and it is a different product: DBConvert Streams replicates MySQL and PostgreSQL continuously and runs anywhere.

Want to browse and query both databases while you migrate? Streams includes a database explorer for MySQL and PostgreSQL →

Supported versions and services

MySQL

  • MySQL 5.x, 8.x; MariaDB; Percona Server
  • Amazon RDS / Aurora MySQL, Azure Database for MySQL, Google Cloud SQL

PostgreSQL

  • PostgreSQL 8.x through 17.x
  • Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, Supabase
  • PostgreSQL schemas (public, custom schemas)

How to migrate MySQL to PostgreSQL

DBConvert opens in GUI mode and walks the job from connection to commit:

1

Connect to MySQL source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to MySQL source database from DBConvert

MySQL source

Use the MySQL connection guide for local MySQL or MariaDB, or read from Amazon RDS / Aurora for MySQL, Azure Database for MySQL, or Google Cloud SQL for MySQL.

2

Connect to PostgreSQL destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to PostgreSQL target database from DBConvert

PostgreSQL target

Connect to self-hosted PostgreSQL, Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.

Steps 3-6: the same for every database pair

Source and target are connected - steps 1 and 2 above. What follows is identical whichever two databases you picked, so it lives in one place. Each step below opens at its own section.

Open the full guide

All four steps in one page, plus software features, command-line mode, scheduler, and system requirements.

See all features

Move MySQL data into PostgreSQL

Download the current build and run the first job against your own database.

Windows Windows 10 or later · 26.3 MB