PostgreSQL

A rebuttal to Uber’s PG/MySQL paper.

Keep in mind, PG has changed since this discussion. A lot of the replication issues are long since put to rest.

The storage sub-systems are the interesting point of difference between these systems. MYSQL’s indexes point to primary keys instead of a CTID. An update to a MySQL row will have same storage location but PG will be a new CTID/page — unless it was a Heap Only Tuple (HOT) update. But this means PG can reduce IO for queries.

As with anything, it’s always a tradeoff. However, database systems in particular are especially sensitive to workload details. The tradeoffs really matter!

A rebuttal to Uber’s PG/MySQL paper.

Keep in mind, PG has changed since this discussion. A lot of the replication issues are long since put to rest.

The storage sub-systems are the interesting point of difference between these systems. MYSQL’s indexes point to primary keys instead of a CTID. An update to a MySQL row will have same storage location but PG will be a new CTID/page — unless it was a Heap Only Tuple (HOT) update. But this means PG can reduce IO for queries.

As with anything, it’s always a tradeoff. However, database systems in particular are especially sensitive to workload details. The tradeoffs really matter!

https://thebuild.com/presentations/uber-perconalive-2017.pdf

hey folks, don't forget that PG has been evolving since then! those replication issues? mostly sorted out now. plus, their storage system can actually cut down on IO for certain queries. 