"Migrate to Postgres" has become popular advice — popular enough that it's worth being suspicious of it. PostgreSQL is an excellent database. It is not automatically the right answer for every workload currently running on MySQL, and a migration carries real risk that needs to be worth taking on.
When the migration is usually worth it
A few genuine, recurring reasons workloads move from MySQL to PostgreSQL:
- Advanced indexing needs. Partial indexes, expression indexes, and GIN/GiST indexes for full-text search or complex data types solve real problems that are awkward or impossible to solve cleanly in MySQL.
- Extensions that unlock new capability. PostGIS for geospatial workloads, pg_cron for in-database scheduling, and — increasingly — pgvector for AI/embedding workloads are reasons teams migrate specifically to gain a capability, not just for the sake of switching engines.
- Stricter data-integrity defaults. Teams that have been repeatedly burned by silent type coercion or lenient constraint enforcement often value PostgreSQL's stricter-by-default behavior enough to justify the migration cost.
- MVCC behavior that fits the write pattern better. Certain concurrent write-heavy patterns behave differently under PostgreSQL's MVCC model than under MySQL's — worth a real benchmark against your actual workload, not a generic benchmark you found online.
When staying on MySQL is the right call
- Deep ecosystem lock-in — ORMs, tooling, and institutional knowledge built around MySQL-specific behavior that would need to be re-validated wholesale.
- A simple, read-heavy CRUD workload where none of PostgreSQL's differentiators are actually being used, and the migration risk has no corresponding upside.
- A replication topology that's already tuned for your specific failure modes, where rebuilding that operational maturity on a new engine is itself a multi-month project.
- No in-house PostgreSQL operational experience, and no partner providing it — a migration without someone who has actually run PostgreSQL in production under load is a real risk, not a paperwork risk.
We've migrated production systems in both directions — MySQL to PostgreSQL, and PostgreSQL environments that stayed exactly where they were because the honest answer was "don't migrate this." The technology preference should follow the workload, not the other way around.
A four-question framework before you decide
- What specific PostgreSQL feature do you actually need that MySQL genuinely can't do well — not "PostgreSQL is generally considered more capable," but a named feature your application needs today or within the next year?
- What's your real downtime budget for the cutover, and does it match what a well-executed migration of your data volume actually requires?
- How much dialect-specific SQL exists in your application layer, stored procedures, and reporting queries that would need to be rewritten and re-tested?
- Do you have in-house PostgreSQL operational experience, or a partner who does, to run the new environment once the migration is done — not just to execute the migration itself?
If the answers to those four questions don't add up to a clear, specific benefit that outweighs the migration cost, the right move is usually to stay put and solve the actual problem you have on the engine you're already running.
Key takeaways
- Migrate for a specific, named capability — not general reputation.
- Weigh migration risk honestly against the workload's actual requirements.
- In-house or partner operational experience with the target engine matters as much as the migration plan itself.