Postgres vs MySQL: Write-heavy sysbench benchmarks on large servers analyzed

We analyze the latest write-heavy sysbench benchmarks comparing modern Postgres and MySQL on high-core servers, breaking down write amplification, concurrency bottlenecks, and what founders should actually deploy.

The sysbench write-heavy workload

The benchmarks detailed by typesanitizer focus on write-heavy sysbench test suites executed on a large bare-metal server. This setup targets the limits of modern relational database engines under sustained, concurrent write pressure. The workloads primarily consist of update-intensive and insert-intensive operations, designed to stress the storage engine, transaction logging, and locking mechanisms of both PostgreSQL and MySQL.

On large servers with high core counts, database performance is rarely limited by raw disk speed alone. Instead, CPU concurrency, lock contention, and memory management become the primary bottlenecks. The sysbench tests highlight how each database handles hundreds of concurrent connections attempting to modify the same tables simultaneously.

Postgres MVCC vs InnoDB undo logs

The core architectural divergence between these two engines dictates their write performance under load. PostgreSQL implements Multi-Version Concurrency Control (MVCC) by writing a new version of a row (a tuple) directly to the table space for every update. This design requires a background process, autovacuum, to periodically clean up dead tuples. Under write-heavy workloads, this causes significant write amplification and can lead to table bloat if autovacuum cannot keep pace.

MySQL, using the default InnoDB storage engine, takes a different approach. It performs updates in-place within the primary index (the clustered index) and writes the historical versions of the row to a separate undo tablespace. This keeps the main table cleaner and reduces immediate write amplification, though it shifts the burden to the InnoDB purge threads that clean up the undo logs.

Checkpoint overhead and write amplification

The Smalldatum benchmarks demonstrate that MySQL generally maintains a more stable throughput profile under sustained write pressure. InnoDB's doublewrite buffer and page-flushing algorithms are highly optimized for high-throughput write environments. While checkpointing still occurs, the performance degradation is typically less severe than what is observed in PostgreSQL.

PostgreSQL performance during heavy writes often exhibits a sawtooth pattern. As dirty pages accumulate in shared_buffers, the database must periodically flush them to disk during checkpoints. If the write volume is high, these checkpoints can saturate the I/O subsystem, causing temporary latency spikes. Furthermore, the need to write full pages to the Write-Ahead Log (WAL) after a checkpoint (to prevent page corruption) further increases write amplification.

What is interesting

The most compelling takeaway from the Smalldatum data is how concurrency scaling behaves on modern, high-core hardware. Historically, MySQL suffered from severe internal lock contention (such as the trx_sys mutex) at high thread counts. Modern MySQL releases have largely mitigated these bottlenecks, allowing InnoDB to scale linearly up to high core counts.

For PostgreSQL, the benchmark shows that while the engine is incredibly robust, it requires meticulous tuning to match MySQL's raw write throughput. Adjusting parameters like max_wal_size, checkpoint_completion_target, and table-specific fillfactor settings is mandatory, not optional, for write-heavy workloads.

What is missing

The benchmark focuses heavily on synthetic sysbench workloads, which use highly uniform transaction patterns. Real-world write-heavy applications rarely write data so cleanly. They often feature highly skewed access patterns, long-running analytical queries running alongside writes, and complex foreign key constraints.

Additionally, the source post does not deeply explore the operational cost of MySQL's undo log accumulation under long-running transactions. While MySQL avoids PostgreSQL's table bloat, a single long-running transaction in MySQL can prevent the purge threads from cleaning up the undo log, leading to massive system tablespace growth and performance degradation.

The investor read

Write-heavy database performance directly impacts infrastructure margins for high-scale SaaS and data-ingest platforms. While PostgreSQL has captured the mindshare of the developer ecosystem, these benchmarks show that MySQL (InnoDB) remains highly competitive, often delivering better raw write efficiency out of the box. For investors, this highlights that the database market is not a winner-take-all game. Companies building high-throughput logging, telemetry, or financial ledger systems may face significantly higher cloud infrastructure bills on PostgreSQL due to write amplification and vacuum overhead. This operational reality sustains the market relevance of MySQL-compatible engines (like AWS Aurora MySQL) and specialized engines like MyRocks. A startup's choice of database can have a material impact on their gross margins at scale, making database architecture a relevant diligence item for infrastructure-heavy investments.

Pull quote: “The core architectural divergence between these two engines dictates their write performance under load.”