Know what breaks before you migrate

Analyze a PostgreSQL schema before moving to MySQL or MariaDB — 21 deterministic checks, run entirely in your browser.

PostgreSQL

Version is auto-detected from your schema — no need to pick it.

Sample schema

Drag & drop a .sql file, or

Basic analysis runs in your browser. Your schema is not uploaded for the standard scan — no database password required.

Need a safe export? pg_dump --schema-only --no-owner --no-privileges DATABASE > schema.sql

What this checks

21 deterministic rules across types, identity/sequences, table options, identifiers, and functions — covering the constructs with no direct MySQL equivalent (arrays, row-level security, table inheritance, materialized views, standalone sequences) as well as the ones with a real but different translation (SERIAL, JSONB, ON CONFLICT, RETURNING). Nothing here is AI-generated prose about your schema; every finding traces back to a specific, tested detection rule. Row data (INSERT statements) is not converted yet for this direction — only the schema structure.

FAQ

How do I check my PostgreSQL version?

Connect with psql or any SQL client and run:

SELECT version();
  • Mac: psql --version in Terminal for a Homebrew install, or check the Postgres.app menu-bar icon if you're using it.
  • Windows: psql --version in Command Prompt, or open pgAdmin and check the server's Dashboard/Properties tab.
  • Linux: psql --version for the client, or pg_lsclusters on Debian/Ubuntu to list every installed cluster and its version.
  • Managed/cloud (RDS, Cloud SQL, Supabase, Neon, etc.): shown directly on the instance's configuration page in the provider's console.

Easiest of all: export with pg_dump as suggested above, and the version is embedded automatically in the dump's header comments — DevEquiv detects it for you, no manual lookup needed.

How do I check my MySQL/MariaDB version to pick the right Target?

The database itself is always the most reliable source — connect with any client and run:

SELECT VERSION();
  • Mac: mysql --version in Terminal for a Homebrew install, or check the MySQL pane in System Settings for the official installer.
  • Windows: mysql --version in Command Prompt if the client is on PATH, or open MySQL Workbench — the version is shown on the connection's home screen.
  • Linux: mysql --version for the client, or check the installed server package — dpkg -l | grep -E 'mysql-server|mariadb-server' on Debian/Ubuntu, rpm -qa | grep -E 'mysql|mariadb' on RHEL/Fedora.
  • Managed/cloud (RDS, Cloud SQL, PlanetScale, etc.): the engine version is shown directly on the instance's configuration page in the provider's console.

Pick whichever version you're actually migrating to — the newest LTS release is a safe default if you haven't decided yet.

Why isn't my row data converted?

PostgreSQL's string-escaping rules, data types (arrays, JSONB, native booleans), and upsert syntax are different enough from MySQL's that converting INSERT statements correctly needs its own dedicated, carefully tested pass — the same way the MySQL → PostgreSQL direction's row-data conversion was built and verified against a real database before shipping. That work is not done yet for this direction. Every data statement in your input is preserved, unconverted, in a clearly marked review block in the downloaded schema — nothing is silently dropped.