Why Uber’s MySQL Switch Misrepresents PostgreSQL: A Deep Technical Dive

Background

Recently an Uber blog post sparked discussion by claiming MySQL should replace PostgreSQL. The original article listed several PostgreSQL shortcomings.

Uber’s Stated PostgreSQL Problems

Inefficient architecture for writes

Inefficient data replication

Issues with table corruption

Poor replica MVCC support

Difficulty upgrading to newer releases

1. Inefficient Architecture for Writes

Uber attributes write‑amplification to PostgreSQL’s MVCC, citing SSD and index write‑amplification. In reality, any DB that supports concurrent reads/writes uses versioning; the cost depends on implementation.

Databases based on rollback segments copy entire data blocks to a rollback area on update, generating additional REDO writes and index changes when the indexed columns change.

Databases using MVCC create a new tuple version. PostgreSQL often updates the tuple in‑place (HOT) without changing the index if the indexed columns stay the same.

Performance test on a table with 10 million rows (8 indexes) updating only the mod_time column showed a sustained update rate of over 130 k rows/second, with no noticeable table or index bloat.

2. Inefficient Data Replication

Uber claims PostgreSQL replication is inefficient. In fact, PostgreSQL’s streaming replication delivers near‑zero latency, supports compression and encryption, and can use logical replication from version 9.4 onward.

Physical replication copies only REDO records, while logical replication may copy full rows, leading to higher network traffic. MySQL’s logical replication also writes both REDO and binlog, doubling write‑amplification.

3. Issues with Table Corruption

Uber cites a PG 9.2 failure during master‑standby failover, but the author could not reproduce such corruption and notes that PostgreSQL’s physical replication guarantees consistency.

4. Poor Replica MVCC Support

Uber states that replica queries block recovery. In PostgreSQL, physical standby queries rarely block recovery; conflicts are limited to exclusive locks, tablespace drops, or vacuum conflicts, all of which can be mitigated with configuration.

5. Difficulty Upgrading to Newer Releases

Contrary to Uber’s claim, PostgreSQL offers straightforward upgrade paths: pg_upgrade for in‑place upgrades and logical replication for incremental upgrades, both supporting major version jumps.

Additional Technical Insights

PostgreSQL’s TOAST mechanism stores large values out‑of‑line, reducing row size and improving update performance.

MySQL InnoDB’s B+‑tree storage can cause write‑amplification due to page splits and requires a primary key for secondary indexes.

PostgreSQL can mitigate index write‑amplification with HOT updates and fillfactor tuning.

Physical replication protects SSDs by using buffer‑based I/O, while direct‑I/O databases suffer more wear.

Conclusion

Both PostgreSQL and MySQL have distinct architectures and trade‑offs. Understanding write‑amplification, replication mechanisms, and upgrade strategies is essential for choosing the right database for a given workload.