Postgres vs MySQL Write Performance

Workload-dependent.

Overview

Postgres and MySQL handle writes through fundamentally different storage mechanics. Postgres uses MVCC with vacuum overhead; MySQL InnoDB uses a clustered index with different write amplification characteristics. Postgres updates all matching indexes on row updates; MySQL only updates indexes on changed columns. Workload shape decides which engine wins; benchmark numbers from synthetic tests rarely survive contact with production traffic.

• Workload-dependent answer. Each engine has workloads where it wins. Benchmarking on the actual access pattern is the only honest test.
• Postgres MVCC. Write creates a new tuple and marks the old one dead. Vacuum reclaims space; bloat is the recurring failure mode.
• MySQL InnoDB. Clustered index per primary key; updates rewrite the row in place. Different write amplification profile.
• Index update behaviour plus real benchmarks. Postgres updates every matching index on UPDATE; MySQL only the changed-column indexes. Production-shaped benchmarks beat general claims every time.

The approach

Three habits keep the comparison evidence-based: benchmark with production-shaped traffic, profile both engines under load, and document the rationale so the choice survives team turnover.

• Workload-shaped benchmark. Anonymised production data, real query mix, real concurrency. Synthetic benchmarks miss the patterns that matter.
• Profile both engines. Per-engine the bottleneck (CPU, IO, lock contention). The bottleneck reveals whether scaling fits the engine.
• Document the rationale. Per-database the choice and the data that supported it.
• Re-evaluate periodically plus operational fit. Engine versions evolve; team expertise often beats theoretical advantage on a 3-year horizon.

Why this compounds

Each evidence-based engine choice deepens the team’s database engineering capability. Tribal preference erodes; data takes its place; new services arrive at decisions faster because the methodology is settled.

• Operational fit improves. Right engine for the workload means fewer scaling surprises in production.
• Team expertise deepens. Each engine teaches database internals the team carries forward.
• Evidence-based culture replaces tribal preference. Decisions become reviewable and survive engineering turnover.
• Year-one investment, year-two habit. First benchmark is heavy lift. By the third comparison, the methodology is muscle memory.