If you've ever tried converting a MySQL database to PostgreSQL (or the reverse), you've probably run into tools that do text replacement on your SQL dump.
They work fine — until they don't.
Where regex converters fail
The edge cases pile up fast:
-
Zero dates (
0000-00-00) — PostgreSQL rejects them outright - AUTO_INCREMENT — needs to become a proper sequence with the counter set to the right value
- ENUM columns — most tools skip them or flatten to VARCHAR
- Backtick quoting — mixed with double quotes causes silent breakage
- Character sets — Latin1 columns with emoji data get mangled
You only discover these after importing into production and seeing broken data.
A different approach
I built SwapSQL to solve this. Instead of parsing SQL text with regex, it:
- Loads your dump into an isolated database sandbox (real MySQL 8.0 or PostgreSQL 16)
- Converts engine-to-engine — schema is read from the live catalog, not from text
- Exports a clean
.sqlfile from the target engine
The output is guaranteed-valid SQL because it comes from a real database, not a string manipulation script.
The reverse direction: PostgreSQL to MySQL
This is the direction almost nobody supports well. PostgreSQL has types that don't exist in MySQL:
| PostgreSQL | MySQL | Notes |
|---|---|---|
uuid |
CHAR(36) |
gen_random_uuid() default maps to (uuid())
|
jsonb |
JSON |
Queryable with MySQL JSON functions |
arrays |
JSON |
Stored as JSON arrays |
timestamptz |
DATETIME(6) |
Converted to UTC, microsecond precision kept |
identity/serial |
AUTO_INCREMENT |
Counter continues from highest existing id |
SwapSQL handles all of these, and the PostgreSQL-to-MySQL output is validated by loading it into a real MySQL server before you download it.
Free tier
Dumps up to 10 MB convert for free, no account needed. SQL compresses roughly 10x, so .sql.gz files are accepted — the free tier effectively covers ~100 MB of raw SQL.
Try it: swapsql.com
If you've dealt with MySQL/PostgreSQL migrations, I'd like to hear what pain points you ran into.
Top comments (0)