Postgres to MySQL Migration: When and How (and Why It Is Rarer Than the Reverse)
Most teams move toward Postgres in 2026. Uber is the canonical exception. Here is the honest picture of when and why Postgres-to-MySQL makes sense.
Why this migration is rarer
The Stack Overflow Developer Survey has named Postgres the most admired database every year since 2022. New projects on Render, Supabase, Neon, Railway, and Heroku default to Postgres. The ecosystem momentum is strongly toward Postgres for new work. Teams do not generally migrate away from Postgres; they adopt it.
The exceptions are real but specific.
The five legitimate reasons
1. You are committing to Vitess at scale
YouTube, Slack, GitHub, and Booking.com all run MySQL via Vitess for sharded OLTP at multi-billion-row scale. Vitess (MySQL) has a more mature sharded OLTP track record than Citus (Postgres). If your scale needs match and you have or can build Vitess expertise, MySQL is the correct answer.
2. You are committing to Oracle Cloud and HeatWave
MySQL HeatWave delivers genuine OLAP performance improvement on Oracle Cloud (OCI) and AWS. If OCI is your platform and analytical queries on MySQL data are a primary workload, HeatWave is a real advantage. The lock-in to OCI is real too. Evaluate with eyes open.
3. You are deep in the LAMP / WordPress / Drupal / Magento ecosystem
Trying to run WordPress on Postgres is documented pain. The WordPress ecosystem is MySQL-native. Magento is MySQL-native. If ecosystem fit is the primary constraint, MySQL or MariaDB is correct and migrating to Postgres would fight the ecosystem.
4. Your team has deep MySQL DBA expertise
MySQL operational knowledge (replication topologies, XtraBackup, ProxySQL, InnoDB tuning) is not trivially transferable to Postgres. The migration cost includes losing 5-15 years of accumulated MySQL operational depth. If your team has it and your Postgres bench is thin, that is a real constraint.
5. The Uber 2016 case
Uber migrated from Postgres to MySQL in 2016 citing write amplification (index update overhead), replication architecture preferences, and their schemaless layer requirements. This is the most-cited Postgres-to-MySQL migration. Important context: the post predates Postgres 9.6 (parallel queries), Postgres 10 (logical replication, declarative partitioning), and Postgres 12-17 (planner improvements). The specific pain points Uber experienced have been addressed in subsequent Postgres releases.
Translation gotchas: Postgres to MySQL
| Postgres feature | MySQL equivalent | What you lose |
|---|---|---|
| RETURNING clause | LAST_INSERT_ID() + SELECT | Single-query atomicity. Two trips required. |
| JSONB with GIN indexes | JSON with generated columns + indexes | GIN index on arbitrary JSON path. More complex to query. |
| Exclusion constraints | No equivalent | Complex uniqueness conditions (e.g., no overlapping date ranges for same entity) require application enforcement. |
| Deferrable foreign keys | No equivalent | Cannot defer FK checks to end of transaction. Some bulk load patterns break. |
| PL/pgSQL + PL/Python etc. | SQL stored procedures only | Multi-language stored procedure capability. Python/R/V8 procedures must be moved to application layer. |
| Concurrent index creation | Online DDL (with limits) | Postgres CONCURRENTLY is very flexible. MySQL Online DDL has documented limits by operation type. |
Should you do this migration?
For most teams in 2026: no. The direction of travel is toward Postgres. The ecosystem, governance, and feature trajectory favour Postgres for new projects. If you are not running Vitess at scale, not committing to Oracle Cloud, and not in a WordPress/LAMP ecosystem, the migration to MySQL is unlikely to pay back.
If you fit one of the five reasons above, the migration may be rational. Go in with realistic timeline expectations (months, not weeks for anything beyond a toy schema), a detailed rollback plan, and eyes open about what you are giving up (RETURNING, GIN indexes, exclusion constraints, PL/pgSQL).