Postgres vs MySQL Performance: 2026 Benchmarks With Sources
Real workload context. Every vendor-sourced figure is labelled. No cherry-picked single-number claims.
Simple point-lookup (primary key read)
Slight edge (~5-15%)
MySQL InnoDB clustered index stores the row data directly with the primary key. Postgres heap storage requires a second lookup (index + heap fetch). For simple pk-lookup workloads at high concurrency, MySQL often has a slight edge.
Complex multi-table joins / analytical queries
Workload-dependent; Postgres planner advantage
Postgres's query planner is generally stronger for multi-table joins with complex predicates, CTEs, and aggregations on mixed workloads. This is why analytics-adjacent OLTP tends toward Postgres.
JSON / JSONB query performance
Significant for complex JSON queries; minor for simple JSON_VALUE
Postgres JSONB with GIN index allows arbitrary JSON path queries at index speed. MySQL JSON_TABLE and generated-column-plus-index approach works but requires more schema engineering. For ad-hoc JSON queries, Postgres JSONB GIN wins.
Insert-heavy / sustained write workloads
MySQL InnoDB tuned for sustained writes; Postgres VACUUM overhead can show
MySQL InnoDB is tightly tuned for sustained insert workloads. Postgres is competitive but under heavy UPDATE workloads, MVCC bloat and autovacuum overhead can surface and require tuning. PG 17 improvements have narrowed this gap.
Connection scaling (1000+ concurrent connections)
Without PgBouncer, Postgres degrades sharply. With PgBouncer: near parity.
Postgres forks an OS process per connection. At 1000+ connections without pooling, memory and context-switch overhead becomes dominant. MySQL uses a thread model (lower per-connection cost). With PgBouncer in transaction mode, Postgres parity is achievable for most workloads.
OLAP / analytical queries (without HeatWave)
Postgres planner advantage on complex OLAP; Citus adds columnar
For analytical queries on a standard non-sharded deployment, Postgres's planner outperforms MySQL. PostgreSQL + Citus or PostgreSQL + pg_analytics (DuckDB extension) adds columnar storage for OLAP. MySQL has no open OLAP acceleration layer (HeatWave is proprietary).
Analytics with MySQL HeatWave (on OCI or AWS)
Oracle claims 400x on some OLAP queries (vendor-sourced; take with context)
MySQL HeatWave's in-memory OLAP acceleration is real for query patterns it supports. Oracle's benchmark figures are vendor-sourced and should be tested against your specific workload. HeatWave is available only on OCI and AWS. Independent benchmarks are limited.
The honest closer
Performance is rarely the deciding factor in a Postgres vs MySQL choice. Both databases are fast enough for 99% of applications. The ownership question, ecosystem fit, operational familiarity, and specific feature requirements (PostGIS, JSONB GIN, exclusion constraints, or Vitess sharding) matter more than raw benchmark throughput.
Choose based on the workload decision matrix. Verify performance with your specific query patterns and data volumes before making a final call.