Postgres vs MySQL Performance: 2026 Benchmarks With Sources

Slight edge; size depends on schema and hardware

MySQL InnoDB stores the table itself in primary-key order, so a PK lookup reads the row straight out of the index. PostgreSQL stores rows in a heap, so an index scan finds a tuple pointer and then fetches the row from the heap, unless the query is satisfied by an index-only scan. That extra step is the structural reason MySQL tends to edge simple PK reads. PostgreSQL 18 (September 2025) added asynchronous I/O, which narrows read-side gaps.

Workload-dependent; Postgres planner has more join strategies

PostgreSQL's planner can cost nested-loop, hash and merge joins and reorder joins across a wider search space, and it parallelises sequential scans, joins and aggregates. MySQL historically planned around nested-loop joins and added hash join only in 8.0.18. On multi-table queries with complex predicates, CTEs and aggregation, that wider strategy set is why analytics-adjacent OLTP tends toward Postgres. This is an architectural reading, not a measured result: run your own queries before treating it as a magnitude.

Structural advantage for ad-hoc JSON paths; parity for a single known path

A Postgres GIN index on a JSONB column answers arbitrary containment and path queries without declaring them up front. MySQL indexes JSON through multi-valued indexes (8.0.17+) for arrays and generated-column or functional indexes for specific scalar paths, so each path you want indexed has to be declared in the schema. Where the query paths are known and stable, MySQL is competitive; where they are ad hoc, Postgres does not need a schema change.

MySQL InnoDB tuned for sustained writes; Postgres VACUUM overhead can show

PostgreSQL's MVCC leaves a dead tuple behind on every UPDATE and DELETE, so sustained write workloads depend on autovacuum keeping up; when it does not, bloat shows up as degraded throughput. InnoDB instead keeps old row versions in a separate undo log. Postgres is competitive on inserts, but heavy UPDATE workloads are where this surfaces and needs tuning. PG 17-18 vacuum memory management and asynchronous I/O narrowed the gap.

Without PgBouncer, Postgres degrades sharply. With PgBouncer: near parity.

PostgreSQL starts a separate backend process per connection, so at 1000+ connections memory and context-switch overhead become dominant. MySQL uses a thread per connection, which costs less each. With PgBouncer in transaction mode multiplexing many client connections onto a small server pool, Postgres reaches practical parity for most workloads.

Same planner advantage; Citus and pg_duckdb add columnar

On a standard non-sharded deployment the analytical edge comes from the same planner breadth as multi-table joins, not from a separate columnar engine: stock Postgres and stock MySQL are both row stores. Postgres has open extensions that add columnar or vectorised execution (Citus, pg_duckdb). MySQL has no open OLAP acceleration layer; HeatWave is proprietary and cloud-only.

400x vs Amazon RDS for MySQL (Oracle's own TPC-H figure)

MySQL HeatWave's in-memory OLAP acceleration is real for the query patterns it supports. Oracle's headline multiples are vendor-published and each one names a different baseline: 400x versus Amazon RDS for MySQL, 1100x versus Amazon Aurora, 18x versus Redshift, all on TPC-H at Oracle's chosen data sizes. A multiple without its baseline and dataset means nothing, so treat these as vendor claims and test your own workload. HeatWave is available only on OCI and AWS, and independent benchmarks are limited.