PostgreSQL
MySQL

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.

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.

What DBConvert does on this path: handles the database move as a repeatable desktop workflow:

  • 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.

What it does not do: PL/pgSQL functions, triggers, rules, and PostgreSQL-specific application SQL (RETURNING, ON CONFLICT, ILIKE, DISTINCT ON, jsonb operators) are not translated to MySQL automatically. Treat that code as an application rewrite task.

Which tool: DBConvert or DBSync?

DBConvert for PostgreSQL → MySQL

One-time conversion. Connect PostgreSQL (on-prem or managed cloud), connect MySQL / MariaDB / RDS / Aurora / Cloud SQL, select objects, review the type mapping, and run through the desktop wizard.

DBSync for PostgreSQL ↔ MySQL

The separate tool when both databases must stay aligned after the first transfer: one-way sync, bi-directional sync, scheduled runs, or trigger-based repeat sync.

Both are Windows desktop tools with a GUI wizard. They are not log-based CDC products - see the alternatives section for that path.

Need more context? Compare DBConvert and DBSync side by side →

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 / BIGSERIALINT / BIGINT AUTO_INCREMENT
TEXTLONGTEXT
BYTEALONGBLOB
BOOLEANTINYINT(1)
TIMESTAMPTZDATETIME (with the application enforcing TZ semantics)
uuidCHAR(36) or BINARY(16) per column

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.

Stored procedures, triggers, and procedural code - out of scope

DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. PL/pgSQL functions, triggers, rules, custom operators, and extension-backed behavior (PostGIS, hstore, pgvector) stay in the source and are rewritten manually in MySQL's stored-procedure dialect - or moved into application code. Typically a small fraction of the schema, but the one item the tool does not handle.

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.

DBConvert vs MySQL Workbench and other options

The PostgreSQL → MySQL converter space splits into a few practical categories. The right choice depends on whether you need a one-time move, a cloud cutover, or repeat sync.

Route Where it fits Where it falls short
pgloader free CLI loader - pgloader only loads into PostgreSQL (from MySQL, SQLite, MS SQL, dBase, CSV). Wrong direction - does not migrate PostgreSQL → MySQL.
MySQL Workbench Migration Wizard free Oracle GUI One-time small-to-medium moves when you already use MySQL Workbench and connect to PostgreSQL via the system ODBC driver. Unsupported PostgreSQL types need manual fixes; no scheduled sync, no reverse direction.
pg_dump + manual MySQL load native CLI Scripted or repeatable command-line workflows when the team is comfortable hand-editing the dump and writing MySQL DDL for the unsupported parts. No GUI, no scheduled sync, no type-mapping review - schema cleanup, type decisions, and validation stay on the team.
Online SQL converters ChartDB, CodeConvert AI Quick syntax checks on a few DDL statements. Not a fit for production data, live database connections, index / foreign-key recreation, or repeat runs.
AWS SCT + AWS DMS log-based CDC, AWS-native Target is Amazon RDS / Aurora MySQL and the rest of the stack lives in AWS. SCT handles schema assessment, DMS handles full-load + ongoing replication. Coupled to AWS endpoints and AWS billing; not useful when the target is outside AWS.
DBConvert / DBSync commercial GUI + sync Visual wizard, object selection, mapped schema + data transfer, PostgreSQL and MySQL cloud endpoints on both sides, optional DBSync to keep both sides aligned after the first move. Commercial license; desktop tool (Windows). For continuous log-based CDC, use DBConvert Streams instead.
DBConvert Streams log-based CDC, runs anywhere Continuous PostgreSQL ↔ MySQL replication when PostgreSQL must stay live until cut-over. Choose over AWS DMS when the pair is outside AWS or you want a focused CDC tool. Commercial license; separate product from the DBConvert desktop suite.

What DBConvert and DBSync actually do

1

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.

2

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.

3

Bi-directional synchronization (DBSync)

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

Supported versions

  • 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 5.x, 8.x; MariaDB; Percona Server
  • Amazon RDS / Aurora MySQL, Azure Database for MySQL, Google Cloud SQL

Supported in this path

Source PostgreSQL
Target MySQL
PostgreSQL Amazon RDS / Aurora for PostgreSQL Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Supabase MySQL MariaDB Percona Server for MySQL Amazon RDS / Aurora MySQL Azure Database for MySQL Google Cloud SQL for MySQL
PostgreSQL

All PostgreSQL Tools

Other directions and pairs
MySQL

All MySQL Tools

Migration & sync options

Reverse Conversion

MySQL to PostgreSQL

Using PostgreSQL to MySQL Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to PostgreSQL source database

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

Connect to PostgreSQL source database from DBConvert

PostgreSQL source

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

2

Connect to MySQL destination database

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

Connect to MySQL target database from DBConvert

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.

More guides for PostgreSQL ↔ MySQL

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options - pick tables, fields, indices, views.
  • Issue detection - the built-in checker flags integrity problems before migration starts.
  • Execute - commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI - rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3-5, software features, command-line mode, scheduler, and system requirements.

See all features