The 'just use Postgres' camp has been growing for years, and for good reason — PostgreSQL is an exceptional database with a feature set that consistently outpaces MySQL for complex workloads. But 'just use Postgres' isn't a complete answer, and MySQL remains the right choice in specific contexts.
This post compares the two honestly, including the cases where MySQL wins, and gives you a practical framework for making the decision for your specific application.
Why this comparison still matters in 2025
The MySQL vs PostgreSQL choice is increasingly settled for new projects — most engineers starting fresh choose PostgreSQL. But the comparison remains highly relevant for:
- Teams evaluating whether to migrate an existing MySQL database to PostgreSQL
- Drupal shops choosing a database for new projects (Drupal traditionally favored MySQL)
- Teams inheriting a codebase and evaluating whether the database choice is limiting them
- Organizations standardizing their database platform across multiple applications
Core architectural differences
Understanding the architectural differences helps explain why each database excels in different scenarios:
MVCC implementation: Both databases use Multi-Version Concurrency Control, but differently. PostgreSQL's MVCC is known for consistent read performance under write load. MySQL's InnoDB MVCC can show more write amplification under sustained concurrent write loads.
ACID compliance: Both are fully ACID-compliant with InnoDB (MySQL's default storage engine). The distinction matters less than it did historically.
Extension ecosystem: PostgreSQL's extension model is a significant differentiator. PostGIS for geospatial, pgvector for AI embeddings, TimescaleDB for time-series, Citus for horizontal scaling — these are production-grade extensions that fundamentally extend what PostgreSQL can do.
Where PostgreSQL wins
- Complex queries — PostgreSQL's query planner is consistently better at optimizing complex queries with multiple joins, window functions, and CTEs.
- JSON/JSONB — PostgreSQL's JSONB type (binary JSON with indexing support) is mature and production-proven. MySQL's JSON support, while improved, lags in performance and indexing flexibility.
- Full-text search — PostgreSQL's full-text search is more capable than MySQL's, with better language support and ranking options.
- Geospatial — PostGIS makes PostgreSQL the clear choice for any application with geospatial requirements.
- Analytics and reporting — window functions, lateral joins, and CTEs are better supported and perform better in PostgreSQL.
- Data integrity — PostgreSQL enforces constraints more strictly and supports a broader set of constraint types.
- Standards compliance — PostgreSQL has historically been more SQL-standard-compliant, which matters for portability.
Where MySQL still wins
MySQL isn't inferior — it's optimized for different things:
- Drupal ecosystem compatibility — Drupal has been optimized for MySQL/MariaDB over decades. Some contrib modules make MySQL-specific assumptions. For Drupal projects, MySQL remains the path of least resistance.
- Simple read-heavy workloads — for straightforward applications with high read volumes and simple query patterns, MySQL can deliver excellent performance with less tuning.
- Hosting compatibility — shared hosting, legacy infrastructure, and many managed hosting platforms default to MySQL. Migration requires infrastructure changes.
- Team familiarity — if your DBA team has deep MySQL expertise, the operational advantage of staying on MySQL can outweigh PostgreSQL's technical advantages.
- MariaDB ecosystem — if you're already on MariaDB (MySQL's open-source fork), many of the gaps with PostgreSQL have been closed, and migration may not be worth it.
Moving from MySQL to PostgreSQL: what to expect
The technical migration is straightforward — tools like pgloader automate most of the data transfer. The harder parts are:
- Query compatibility — MySQL and PostgreSQL handle some SQL constructs differently. GROUP BY behavior, string comparison case sensitivity, and date function syntax all need review.
- Application-level changes — ORMs generally abstract these differences, but raw SQL queries need review.
- Character encoding — PostgreSQL defaults to UTF-8; MySQL historically allowed mixed encodings that can cause issues on migration.
- Performance re-tuning — query plans differ between the two databases. Queries optimized for MySQL may need index adjustments on PostgreSQL.
{ our take }
For new projects: choose PostgreSQL unless you have a specific reason not to. For existing MySQL systems: evaluate migration only when the pain of staying is real — slow complex queries, JSON storage requirements, geospatial needs. Don't migrate for its own sake.