Migrate MySQL to PostgreSQL
Certified — live-tested pathMigrating from MySQL (the world's most deployed open-source relational database) to PostgreSQL (the most advanced open-source relational database) means every table, column type, key, index and row has to survive two engines' different opinions about data. DBShifts converts the schema with deterministic rules, transfers data in parallel batches, and validates the result with per-table row counts and type-aware checksums.
Free tier · no credit card
How the migration works
Connect
Point DBShifts at your source and target. Credentials stay encrypted; SSH tunnels supported for private databases.
Analyze
Automatic schema introspection produces a migration plan: what converts automatically, what migrates with warnings, what needs human review.
Migrate
Schema is created on the target, data transfers in parallel batches with constraints deferred, indexes rebuilt after load.
Validate
Per-table row counts, type-aware checksums on both sides, FK integrity — plus a fidelity report listing anything lossy.
What DBShifts handles for MySQL → PostgreSQL
Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.
- TINYINT(1) is treated as a boolean; plain TINYINT stays numeric — converting both blindly corrupts ratings and counters.
- UNSIGNED integers are widened on targets without unsigned types, so values above the signed range survive.
- ENUM and SET columns are converted with their value lists preserved (native enums, CHECK constraints, or arrays depending on the target).
- TIME columns are durations (-838h..838h) at the driver level — DBShifts converts them per target instead of failing the batch.
- Zero dates (0000-00-00) are normalized deterministically and reported, never silently dropped.
- Bulk loads use sequence reseeding (setval to MAX) so SERIAL columns keep working after migration.
- ENUMs from MySQL become native CREATE TYPE … AS ENUM — validation semantics preserved.
- Foreign keys and indexes are applied after data load for dramatically faster transfers.
Frequently asked questions
Is MySQL to PostgreSQL migration production-ready in DBShifts?
Yes — MySQL to PostgreSQL is a certified pair. It passed DBShifts's live certification suite (schema conversion, data transfer, row counts, type-aware checksums over an edge-case fixture) and is battle-tested in production use.
How does DBShifts verify the MySQL to PostgreSQL migration was correct?
Three layers: per-table row counts on both sides, an order-independent type-aware checksum of row data (canonicalized so engine representation differences don't false-alarm), and FK integrity checks on the target. Rows that fail to insert are quarantined with the exact error — never silently dropped — and can be fixed and retried from the UI.
What happens to MySQL types that PostgreSQL doesn't have?
They convert by deterministic rules with a recorded decision: a native equivalent where one exists, a portable fallback (TEXT/JSON/DECIMAL) where one doesn't. Every lossy conversion appears in the migration plan before you run and in the fidelity report after. You can override any mapping per column.
Can I keep MySQL and PostgreSQL in sync after the initial migration?
Yes. DBShifts supports incremental sync (UPSERT-based delta transfers on a sync key) and, for supported sources, real-time change data capture so the target stays current until you cut over.
Do I need to write any SQL or scripts for MySQL to PostgreSQL?
No. Connect both databases, review the generated migration plan (what's automatic, what migrates with warnings, what needs manual review — typically triggers and stored procedures), and run. Procedural code is transpiled best-effort and queued for human review rather than auto-applied.
What's the hardest part of moving MySQL to PostgreSQL?
Type-system mismatches that fail silently rather than loudly — MySQL's edge-case types (5 engine-specific rules apply) converting into PostgreSQL's nearest equivalent. DBShifts's deterministic mapping records every downgrade in the fidelity report, so a value that clips, rounds, or widens is visible before cutover, not after.
Go deeper
Related migration paths
Ready to move MySQL to PostgreSQL?
Set up in under two minutes. Validation and rollback included.
Start Free Migration