Convert MySQL to Postgres (and Postgres to MySQL) Online

Moving a database between engines usually means rewriting CREATE TABLE statements, data types and query syntax by hand. This free converter does the heavy lifting: paste your SQL, pick the source and target, and get clean, ready-to-review code for PostgreSQL, MySQL or SQLite, with nothing to install.

What is a MySQL to Postgres converter?

MySQL and PostgreSQL both speak SQL, but each has its own dialect. MySQL uses backticks around names and AUTO_INCREMENT for counters; PostgreSQL uses double quotes and identity columns or SERIAL. Types, defaults, index syntax and even string comparison rules differ too. A MySQL to Postgres converter translates those differences automatically, so a schema or query written for one engine can run on the other.

This tool converts in both directions, so it works as a Postgres to MySQL converter online as well, and it can translate MySQL statements for SQLite when you need a lightweight embedded database. It focuses on the part developers dread most: rewriting table definitions and queries line by line.

How to convert MySQL to Postgres

1. Paste your MySQL SQL into the input box. A single CREATE TABLE, a batch of statements or a query all work.
2. Select the direction: MySQL → PostgreSQL (or PostgreSQL → MySQL, or MySQL → SQLite).
3. Click Convert. Data types, quoting, auto-increment keys and common functions are rewritten for the target.
4. Copy the result and run it against a test database first. Tidy it up with our SQL beautifier if you want it neatly formatted.

Prefer to work from a full mysqldump file? Convert the schema here, then move rows with a loader such as pgloader or COPY, as described in the PostgreSQL documentation.

Convert a MySQL CREATE TABLE to Postgres (example)

Here is a typical MySQL table and what the same table looks like in PostgreSQL after conversion:

CREATE TABLE `orders` (
  `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  `status` ENUM('new','paid','shipped') NOT NULL,
  `total` DECIMAL(10,2) NOT NULL,
  `is_gift` TINYINT(1) DEFAULT 0,
  `meta` JSON,
  `placed_at` DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE "orders" (
  "id" BIGINT GENERATED BY DEFAULT
       AS IDENTITY PRIMARY KEY,
  "status" TEXT NOT NULL
       CHECK ("status" IN ('new','paid','shipped')),
  "total" NUMERIC(10,2) NOT NULL,
  "is_gift" BOOLEAN DEFAULT FALSE,
  "meta" JSONB,
  "placed_at" TIMESTAMP NOT NULL
);

MySQL ↔ PostgreSQL data type mapping

Getting types right is the heart of any conversion. These are the mappings you’ll see most often. For the full lists, see the official MySQL data types reference.

Convert Postgres to MySQL

Going the other way is just as common: a team standardizes on MySQL or MariaDB for hosting, or needs a schema that a MySQL-only CMS or plugin can read. When you convert Postgres to MySQL, the converter reverses the mapping above:

• SERIAL / identity columns become AUTO_INCREMENT
• BOOLEAN becomes TINYINT(1)
• BYTEA becomes BLOB, and JSONB becomes JSON
• Double-quoted names become backtick-quoted names
• PostgreSQL-only syntax such as :: casts and ILIKE is rewritten with CAST() and LIKE

MySQL to SQLite query migration

SQLite is a lightweight, file-based database that’s ideal for local development, mobile apps and tests. A MySQL to SQLite query migration tool has to handle an even bigger jump, because SQLite uses just a handful of storage classes. The usual rewrites are:

SQLite is flexible about types, which is convenient but means values aren’t strictly enforced. Read how it works in the official SQLite datatypes guide before relying on it for production data.

Why use this converter?

You could rewrite every statement manually, or write a script, but a dedicated converter is faster and less error-prone. Here’s why people use a tool like this for MySQL, Postgres and SQLite migrations:

Benefits of converting MySQL to Postgres

Teams move from MySQL to PostgreSQL for a range of practical reasons. The main benefits people look for are:

• Closer SQL standards: PostgreSQL follows the SQL standard closely, which makes queries more portable.
• Richer data types: JSONB, arrays, ranges and UUIDs are built in.
• Advanced features: window functions, common table expressions and a large extension ecosystem (such as PostGIS for geographic data).
• Strong consistency: robust constraints and transactional behavior suit data-critical applications.
• Less manual work: converting the schema automatically means you spend your time on testing rather than retyping.

Neither database is “better” for every project. MySQL remains a great choice for many web apps, including WordPress sites, which are built on it. The right choice depends on your workload, your team and your hosting.

What to check after converting

Automatic conversion handles the mechanical differences, but a few behaviors differ at runtime, so always test before going live:

• Case sensitivity: MySQL string comparisons are typically case-insensitive by default; PostgreSQL’s are case-sensitive. Use ILIKE or LOWER() where needed.
• Zero dates: values like 0000-00-00 are valid in some MySQL setups but rejected by PostgreSQL. Clean them to NULL.
• Unsigned numbers: check that widened integer types still fit your data and your application code.
• Stored procedures and triggers: procedural code differs most between engines and usually needs manual rewriting.
• Indexes and keys: confirm every primary key, unique key and index made it across, and that identity sequences start after your highest existing ID.
• Test on a copy: run converted SQL on a staging database and compare row counts before touching production.

Related tools

• CSV ↔ SQL converter: turn CSV files into SQL tables and queries, and back.
• JSON ↔ SQL converter: move JSON data in and out of SQL.
• SQL minifier and beautifier: format converted SQL so it’s easy to review.
• WordPress query generator: build WP_Query code for MySQL-powered WordPress sites.

See every utility in our free online tools collection.

Frequently asked questions