MySQL vs PostgreSQL: Which Database Handles High‑Throughput Writes Faster?

Test Overview

This article translates and summarizes a performance benchmark originally created by Anton Putra, comparing MySQL 9.0 and PostgreSQL 17.0 on a series of ingestion and retrieval tests. The focus is on latency (p99), throughput (queries per second), saturation (CPU and memory usage), disk I/O, and connection‑pool handling.

Test Design

Two tables— Customer (with primary key ID, name, address) and Event (with primary key ID, foreign key to Customer, and action type)—were created in each database. The benchmark uses a Golang client that accesses both databases through the generic database/sql interface to keep the driver impact minimal. PostgreSQL 17.0 and MySQL 9.0 are the latest versions at the time of testing.

First Test – Data Ingestion

The first test measures how quickly each database can insert randomly generated customer IDs and action types. Metrics include:

Insertion request latency (p99 percentile)

Throughput (requests and inserts per second)

Saturation indicators: CPU usage, memory usage, disk write operations, and storage efficiency

Connection‑pool behavior (max connections, per‑client limits)

Multiple client processes are launched, increasing load every 60 seconds and running for nearly three hours (compressed in the presentation to a few minutes).

Key Findings

From the start, PostgreSQL’s insertion latency is noticeably lower than MySQL’s.

MySQL’s insertion time is roughly twice that of PostgreSQL.

PostgreSQL consumes less CPU, indicating a higher throughput ceiling.

Memory usage is also lower for PostgreSQL.

MySQL requires more disk operations to store the same number of records; PostgreSQL’s on‑disk storage efficiency is higher.

Both databases’ connection pools eventually reach 80 connections (40 per client).

Critical point: when QPS reaches about 5,500, MySQL begins to lag, while PostgreSQL continues up to ~19,000 QPS on a 4‑core CPU with direct‑attached SSD.

Second Test – Data Retrieval

The second test evaluates read performance using a simple JOIN query on roughly 70 million rows. Before the test both databases are restarted to clear caches.

Query the Event table, join with Customer , and return user name, address, and action type.

Measure read latency, QPS, CPU and memory usage, disk read operations, and connection‑pool statistics.

Key Findings

The latency gap between the two databases is smaller than in the write test, but PostgreSQL still maintains lower latency.

MySQL’s CPU usage spikes significantly earlier, causing performance degradation around 18,000 QPS.

PostgreSQL remains stable up to about 32,000 QPS before CPU reaches ~90 % and performance starts to decline.

Conclusion

Across both ingestion and retrieval workloads, PostgreSQL outperforms MySQL in latency, throughput, CPU and memory efficiency, and disk storage efficiency. The benchmark indicates that PostgreSQL is better suited for high‑throughput, write‑intensive scenarios, while MySQL reaches its performance limits earlier.