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.

Direct answer

Neither PostgreSQL nor MySQL is universally faster. The winner depends on the workload.

Across seven common workloads, MySQL holds a slight edge on simple primary-key reads, sustained insert-heavy writes, and raw connection scaling without pooling. PostgreSQL leads on complex multi-table joins, JSONB / document queries, and analytical (OLAP) workloads. For 99% of applications both are fast enough, so ownership, ecosystem fit, and feature requirements usually matter more than raw benchmark throughput.

WorkloadWinnerMargin
Simple point-lookup (primary key read)MySQLSlight edge (~5-15%)
Complex multi-table joins / analytical queriesPostgresWorkload-dependent; Postgres planner advantage
JSON / JSONB query performancePostgresSignificant for complex JSON queries; minor for simple JSON_VALUE
Insert-heavy / sustained write workloadsMySQLMySQL InnoDB tuned for sustained writes; Postgres VACUUM overhead can show
Connection scaling (1000+ concurrent connections)MySQLWithout PgBouncer, Postgres degrades sharply. With PgBouncer: near parity.
OLAP / analytical queries (without HeatWave)PostgresPostgres planner advantage on complex OLAP; Citus adds columnar
Analytics with MySQL HeatWave (on OCI or AWS)MySQL HeatWaveOracle claims 400x on some OLAP queries (vendor-sourced; take with context)

Margins are workload-dependent and include vendor-sourced figures (flagged below). Replicate against your own workload before deciding.

Workload lens — pick what describes your workload
Showing all 7 scenarios — toggle above to narrow

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: PG 18 (Sept 2025) asynchronous I/O narrows read-side gaps

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. Recent PG 17-18 improvements (vacuum memory management, asynchronous I/O) 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.

GIN index vs MySQL indexingFeature parity 2026Workload decision matrixOperational reality