PostgreSQL to MySQL Converter

Move PostgreSQL data into MySQL or MariaDB. Schema conversion, type mapping, and optional two-way sync between on-prem and cloud-hosted MySQL.

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

Download DBConvert Order from US$ 199

Windows 10 or later

Most PostgreSQL to MySQL migrations are driven by application stack alignment.

The app, CMS, hosting tier, or operations team standardizes on MySQL or MariaDB. The data copy is straightforward; the work is in deciding how to represent PostgreSQL-only features once MySQL becomes the target. DBConvert connects to both servers, proposes a MySQL type for every column, and creates the tables before it moves a row.

Reads PostgreSQL sources from on-prem servers, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.
Creates MySQL-compatible tables, maps data types, copies rows, and recreates supported indexes and foreign keys.
Writes to MySQL, MariaDB, Percona Server, Amazon RDS / Aurora MySQL, Azure Database for MySQL, or Google Cloud SQL.
Converts the database once, or keeps PostgreSQL and MySQL 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 PostgreSQL server and a live MySQL 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 pg_dump 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 PostgreSQL and MySQL connected

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

One-time conversion

Connect PostgreSQL on-prem or in managed cloud, connect MySQL / MariaDB / RDS / Aurora / Cloud SQL, select objects, review the type mapping, and run it through the wizard.

Repeat synchronization

Keep both databases in use after the first transfer: run the job on a schedule, in one direction or in both, until the PostgreSQL server is retired.

What needs attention

How DBConvert handles the PostgreSQL → MySQL differences

PostgreSQL and MySQL differ in type mapping, sequence model, index features, and procedural code. DBConvert maps most of those differences in the wizard with sensible defaults that you can review or override per table; PL/pgSQL rewrite and PostgreSQL-only application SQL are the two items that still need a human.

Type mapping

PostgreSQL type	MySQL default
`SERIAL` / `BIGSERIAL`	`INT` / `BIGINT AUTO_INCREMENT`
`TEXT`	`LONGTEXT`
`NUMERIC(p,s)`	`DECIMAL(p,s)`
`BYTEA`	`LONGBLOB`
`BOOLEAN`	`BOOL` - MySQL's own alias for `TINYINT(1)`
`TIMESTAMPTZ`	`DATETIME` (with the application enforcing TZ semantics)
User-defined `enum` type	`LONGTEXT` - the labels are kept as text, the type itself is not recreated
Array (`text[]` and friends)	`LONGBLOB` - MySQL has no array type, so plan how the application should read it
`tsvector`	`VARCHAR(255)` - full-text search is rebuilt with a MySQL `FULLTEXT` index

Each mapping is overridable in the type-mapping review.

Sequences and identity

Collapses PostgreSQL standalone sequences into MySQL AUTO_INCREMENT columns and sets the high-water value above the loaded maximum key value before the application resumes inserts - standard MySQL has no separate sequence object to manage.

Indexes and constraints

Recreates PostgreSQL partial-index semantics on MySQL where possible (filtered storage logic, generated columns), and reports GIN / GiST / exclusion constraints that have no direct MySQL analogue in the migration log so the business rule can be rebuilt with MySQL full-text / spatial indexes or application logic.

Application SQL portability

PostgreSQL-specific query syntax (RETURNING, ON CONFLICT, DISTINCT ON, ILIKE, array and jsonb operators, double-quoted identifiers) does not run unchanged on MySQL. DBConvert moves the schema and data; the application SQL layer is its own task - usually a search-and-replace pass plus a test cycle.

Procedural code stays behind

The migration covers tables - their fields, types, defaults, and indexes - and the foreign keys between them. PL/pgSQL functions, triggers, rules, custom operators, and extension-backed behavior (PostGIS, hstore, pgvector) stay in the source and are rewritten by hand in MySQL's stored-procedure dialect, or moved into application code. 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 each source column and the MySQL type it is about to get. On this table the PostgreSQL-only types are the ones to look at: the mpaa_rating enum arrives as LONGTEXT, special_features is an array and lands as LONGBLOB, and the tsvector search column becomes VARCHAR(255). Change any of them before the run.

DBConvert type-mapping review for a PostgreSQL to MySQL conversion, showing an enum, an array and a tsvector column with the MySQL type each will get

Why move

Why teams move PostgreSQL workloads to MySQL

Application stack alignment

CMSs (WordPress, Joomla, Magento, Drupal), SaaS integrations, and LAMP-style application stacks expect MySQL or MariaDB. The migration is usually about matching what the application or hosting provider was built for.

Hosting and managed-tier ubiquity

Every major cloud and most shared-hosting tiers offer MySQL, MariaDB, or a MySQL-compatible managed database. Standardizing on MySQL simplifies hosting and team onboarding when the organization has more MySQL operators than PostgreSQL ones.

Operational simplicity

Smaller engineering teams often prefer the MySQL operational model: simpler replication, smaller default install, well-known tooling, and a large pool of MySQL expertise to hire from.

Replica and reporting alignment

When the rest of the data platform - replicas, reporting copies, analytics extracts - runs on MySQL, moving the primary to MySQL removes a heterogeneous link in the pipeline.

If you need continuous replication instead

Scheduled synchronization is enough for a staged cut-over that runs for days or weeks. When PostgreSQL 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 PostgreSQL and MySQL continuously and runs anywhere.

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

What DBConvert actually does

Wizard with object selection

Connect source and target through the desktop wizard, choose schemas, tables, columns, and row filters, review the type mapping, then run. The session is saved and can be re-run from the scheduler or the command line.

Parallel migration engine

The transfer splits each large table into ranges and copies them concurrently across multi-core CPUs. For tables in the millions-of-rows range, this is the difference between an overnight run and a coffee break.

Bi-directional synchronization

When the cut-over has to be staged - the source database stays live while the target catches up - synchronization replays Insert / Update / Delete one-way or bi-directionally, with a trigger-based mode that avoids full-table compares on subsequent runs. Use it to keep both databases matched during a step-by-step cut-over, not as a CDC replacement.

Supported versions and services

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)

MySQL

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

DBConvert Studio

30+ databases · cloud · scheduled sync

Need more directions or unattended sync? One tool covers them all.

How to migrate PostgreSQL to MySQL

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

Connect to PostgreSQL source database

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

PostgreSQL source

Read from self-hosted PostgreSQL, Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, or Google Cloud SQL.

Connect to MySQL destination database

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

MySQL target

Use the MySQL connection guide for local MySQL or MariaDB, or Amazon RDS / Aurora for MySQL, Azure Database for MySQL, or Google Cloud SQL for MySQL. Create the target schema as utf8mb4.

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 PostgreSQL data into MySQL

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

Download DBConvert 4.4.2 Order from US$ 199

Windows 10 or later · 26.3 MB