MySQL
PostgreSQL

MySQL to PostgreSQL Converter

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

MySQL and PostgreSQL disagree on enough small things that the row copy is rarely what breaks.

The dialect gaps decide the migration, not the bulk transfer.

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

  • Reads MySQL, MariaDB, or Percona sources from on-prem servers, Amazon RDS / Aurora, Azure Database for MySQL, or Google Cloud SQL.
  • Creates PostgreSQL target tables with mapped types, indexes, and foreign keys.
  • Transfers the whole database or selected objects into PostgreSQL, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.

What it does not do: MySQL views, triggers, and stored procedures using MySQL-specific SQL are not rewritten into PL/pgSQL — treat that code as a separate engineering task.

Which tool: DBConvert or DBSync?

DBConvert for MySQL → PostgreSQL

One-time conversion. Connect source and target, review mappings, select objects, and run through the desktop wizard.

DBSync for MySQL ↔ PostgreSQL

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

Both products are Windows desktop tools with a GUI wizard, not an online paste-a-dump converter.

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

How DBConvert handles the MySQL → PostgreSQL differences

MySQL and PostgreSQL differ in identity columns, integer signedness, boolean ambiguity, enums, identifier case, and zero dates. DBConvert maps most of those differences in the wizard with sensible defaults that you can review or override per table; MySQL routines are the one item that still needs a human rewrite.

  • Auto-increment and sequences. Maps MySQL AUTO_INCREMENT to a PostgreSQL identity column or sequence, and resets the sequence above the current maximum key value after the bulk load — so the next insert does not collide.
  • Unsigned integers. Widens MySQL unsigned integer types into PostgreSQL signed equivalents (INT UNSIGNED → BIGINT, smaller unsigned types to wider signed) and can attach a CHECK (col >= 0) constraint to preserve the non-negative guarantee where it matters.
  • Boolean and small-integer ambiguity. Treats MySQL TINYINT(1) as a boolean candidate in the type-mapping review — pick PostgreSQL boolean when the column is truly 0/1, or keep smallint when it stores integer codes.
  • ENUM, SET, and JSON. Converts inline MySQL ENUM definitions to a PostgreSQL enum type (or text column with CHECK), maps SET to an array or lookup-table policy you pick once, and routes MySQL JSON to PostgreSQL jsonb by default.
  • Identifier case and zero dates. Normalizes MySQL mixed-case identifiers to PostgreSQL's lowercase folding (or preserves quoting as-is per your policy), truncates names to PostgreSQL's 63-byte limit when needed, and rewrites MySQL placeholder dates such as 0000-00-00 into NULL on load so PostgreSQL's stricter date validation does not reject the row.
  • Stored procedures, triggers, and functions — outside DBConvert's scope. DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. MySQL stored procedures, functions, and triggers stay in the source and are rewritten manually in PL/pgSQL — MySQL's procedural syntax (DELIMITER, SIGNAL, MySQL-specific error handling) has no direct PL/pgSQL equivalent. Typically a small fraction of the schema, but the one item the tool does not handle.

Why teams move MySQL workloads to PostgreSQL

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

PostgreSQL gives first-class support for jsonb, arrays, ranges, geometric types, full-text search, and user-defined types. Schemas that pushed this logic into application code can move more of it into the database.

Indexing options

PostgreSQL offers B-tree plus GIN, GiST, SP-GiST, BRIN, hash, partial, and expression indexes for query patterns MySQL indexes do not model cleanly.

Extension ecosystem

PostGIS, pgvector, TimescaleDB, Citus, and other PostgreSQL extensions matter when the roadmap includes geo, vector search, time-series, or scale-out work.

DBConvert vs pgloader and other options

Pick by the workflow you need, not by the longest feature list.

Route Where it fits Where it falls short
pgloader free CLI loader Technical evaluation and one-off scripted loads into PostgreSQL. No GUI review, no reverse direction, no repeat jobs, no scheduled sync.
Online SQL converters Small DDL snippets and quick syntax checks. Not a safe place to paste production data; no live database connection, keys, sequences, or repeatable sync.
Schema-diff and migration frameworks Flyway, Liquibase, ORM After the application already has a PostgreSQL model — for ongoing schema evolution. Does not replace the initial copy from MySQL production.
AWS DMS log-based CDC, AWS-native Target is Amazon RDS / Aurora and the rest of the stack already lives in AWS. Native cloud path, nothing to install. Coupled to AWS endpoints and AWS billing; not useful when the target is outside AWS.
DBConvert / DBSync commercial GUI + sync Visual wizard with object selection, mapped schema + data transfer to MySQL and PostgreSQL cloud endpoints, and optional DBSync jobs during a staged cut-over. Commercial license; desktop tool (Windows). For continuous log-based CDC, use DBConvert Streams instead.
DBConvert Streams log-based CDC, runs anywhere Continuous MySQL ↔ PostgreSQL replication when the source must stay live until cut-over and scheduled desktop sync is not enough. 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.
Read the full pgloader vs DBConvert comparison

Supported versions

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

Supported in this path

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

All MySQL Tools

Other directions and pairs
PostgreSQL

All PostgreSQL Tools

Migration & sync options

Reverse Conversion

PostgreSQL to MySQL

Using MySQL to PostgreSQL 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 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.

More guides for MySQL ↔ PostgreSQL

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