// MySQL to PostgreSQL migration
Migrate MySQL to PostgreSQL.
Move the data with open-source tools, then keep one team for the support afterwards.
OSSeva provides MySQL to PostgreSQL migration for teams that want to run PostgreSQL on their own servers, VMs, Kubernetes or cloud account, and supports the new cluster from the day of cutover. Schema and data move with open-source tools such as pgloader and ora2pg, which you keep after we leave. pgloader does not migrate views or triggers, so those and any stored procedures are rewritten and tested by people. OSSeva sizes each migration to the customer's deployment, so the plan comes after the assessment, and it says so when staying on MySQL is the better choice.
Trusted globally by enterprises
Where MySQL to PostgreSQL migrations slow down
Copying the rows is the quick part. The time goes into types, code and the applications.
Types and defaults do not map one to one
pgloader's default casting rules turn tinyint(1) into boolean, auto_increment columns into serial or bigserial and datetime into timestamptz, convert MySQL zero dates to NULL and lower-case identifiers. Each rule changes what the application reads back, so every cast is written down and tested.
Views and triggers do not come across
pgloader's documented limitations: views and triggers are not migrated, and of the geometric types only POINT is covered. Views, triggers and stored procedures are rewritten in SQL and PL/pgSQL and reviewed alongside the data load.
MySQL SQL lives in the application
Queries written for MySQL carry its functions and its sql_mode behaviour. In some modes || means OR in MySQL, while in PostgreSQL it joins strings, and ora2pg has a setting for exactly that case. Every query path has to be found and tested before cutover.
Nobody owns PostgreSQL after cutover
A MySQL team that moves to PostgreSQL takes on a new engine, a new high-availability setup and a new patch cycle. Without support planned from day one, the old MySQL servers tend to stay running beside the new cluster.
The dates that matter
2023-10-25
MySQL 5.7.44 released, the final 5.7 release.
2026-04-21
MySQL 8.0.46 released, the final 8.0 release. MySQL 8.0 reaches end of life that month.
2029-11-08
Final community release of PostgreSQL 17.
2030-11-14
Final community release of PostgreSQL 18.
What OSSeva delivers
Assess and plan
An inventory of schemas, views, triggers, stored procedures, data volumes and every application that connects. ora2pg's MySQL migration assessment gives a first read, and we add the application-side review it cannot see. The written plan names a target PostgreSQL version, or says where MySQL 8.4 or MariaDB fits better.
Convert and load
pgloader creates the tables, indexes, foreign keys and sequences in PostgreSQL and loads the data under casting rules we write down with you. Views, triggers and stored procedures are rewritten and reviewed by hand.
Validate and cut over
Rehearsed loads with row counts and checksums compared on both sides, applications run against PostgreSQL alongside MySQL, and a cutover runbook with go and no-go checks and a rollback plan, run with your team in the change window.
Support from day one
The new cluster moves straight into OSSeva PostgreSQL support: signed builds, Patroni or repmgr, upgrade planning to 17 or 18 on Assure, and on OSSeva Operate 24/7 replication and failover monitoring with a 15-minute P1 incident response SLA.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Stay on MySQL and upgrade to 8.4 LTS | No migration, on an LTS line with Oracle Premier Support to April 2029 | Authentication and replication changes to test. If PostgreSQL features are not the reason to move, this is often the better choice. |
| Move to MariaDB | A MySQL-compatible open-source engine | From MySQL 8.0 it is a dump and load with compatibility testing, and it is still a different engine. |
| Managed PostgreSQL in a public cloud | A hosted target and the provider's own migration services | The database stays on that provider's service and version calendar. |
| Do it yourself with pgloader and ora2pg | Free open-source tools and full control | Your team carries the code rewrite, the cutover and running PostgreSQL afterwards. |
| OSSeva migration and support | One team from assessment through cutover, then PostgreSQL support on your infrastructure | A services engagement followed by a subscription, priced per cluster. |
Tool behaviour from the pgloader MySQL reference, the Ora2Pg project site and its README, and support dates from the PostgreSQL versioning policy and the MySQL release notes, all checked on 9 October 2026. OSSeva coverage from the OSSeva PostgreSQL and MySQL technology pages.
Frequently asked questions
How do I migrate MySQL to PostgreSQL?
Assess the schemas and the applications, load the schema and data into PostgreSQL with a tool such as pgloader, rewrite the views, triggers and stored procedures, validate the data, run both systems side by side, then cut over with a rollback plan. The parallel run is where most surprises show up.
What is the best tool for MySQL to PostgreSQL data migration?
pgloader is the usual choice for data: one command reads a MySQL database, creates the tables in PostgreSQL, loads the rows and builds the indexes. Ora2Pg also accepts MySQL and MariaDB as a source, with migration assessment reports and schema and data export. Both are free and open source.
Does pgloader migrate views and triggers?
No. Its documentation lists views and triggers as not migrated, and of the geometric types only POINT is covered. It can read a MySQL view as if it were a table, which moves the data but does not recreate the view.
Can ora2pg migrate MySQL to PostgreSQL?
Yes. Ora2Pg is best known for Oracle, but its project site and README list MySQL and MariaDB as sources. Its data export is offline, so the final copy happens in a change window.
How long does a MySQL to PostgreSQL migration take?
It depends on the deployment, so we do not quote a duration up front. OSSeva sizes each migration to the customer's deployment after the assessment, counting schemas, stored code, data volume and the applications that connect.
Should we move from MySQL to PostgreSQL at all?
Not always. If MySQL works for you and the goal is a supported version, an upgrade to 8.4 LTS, or patched 8.0 builds while you plan it, is less work. Teams usually move for PostgreSQL features or to run one database engine across the estate.
Can OSSeva support MySQL while we migrate?
Yes. MySQL 5.7 and 8.0 get patched builds after Oracle's end of life, and 8.4 and 9.7 LTS are supported, under the same contract as the new PostgreSQL clusters.
How is it priced?
The migration is a services engagement, and the support afterwards is priced per cluster. Book a discovery call for a quote.
Leave MySQL with the team that will support PostgreSQL afterwards.
Book a discovery call for an assessment plan and a quote. Support is priced per cluster.