Framing first: Benchmarks are workload-dependent. One number without workload context is misleading. Every entry below includes the workload type, winner, magnitude, and source type (independent vs vendor). Replicate any benchmark against your specific workload before making a decision.

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)

MySQL winsIndependent

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.

Source: Various sysbench benchmarks; note: closing gap in PG 17 index-only scans

Complex multi-table joins / analytical queries

Postgres winsCommunity

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.

Source: Lukas Fittl (pganalyze) benchmark series; TPC-H style queries

JSON / JSONB query performance

Postgres winsIndependent

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.

Source: Various 2024 JSONB vs MySQL JSON benchmarks; results vary by query pattern

Insert-heavy / sustained write workloads

MySQL winsCommunity

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.

Source: Various sysbench OLTP-insert benchmarks; context-specific

Connection scaling (1000+ concurrent connections)

MySQL winsCommunity

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.

Source: pgBouncer documentation; various connection-scaling benchmarks

OLAP / analytical queries (without HeatWave)

Postgres winsCommunity

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).

Source: TPC-H benchmarks on Postgres vs MySQL; multiple sources

Analytics with MySQL HeatWave (on OCI or AWS)

MySQL HeatWave winsVendor

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.

Source: oracle.com/mysql/heatwave (vendor-sourced; verify independently)

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.

Feature parity 2026Workload decision matrixOperational reality