Database Articles

[benclmnt]

Uber's switch from PostgreSQL to MySQL (2016)

tl;dr: Uber has a lot of secondary indexes. Some of Postgres MVCC design suffer from write amplification as all indexes needs to be updated on any tuple update + replication amplification as all update needs to be written to WAL, and WAL will need to be shipped to replicas.

• PostgreSQL (before version 10) uses physical replication via WAL shipping, whereas InnoDB supports statement-based replication & logical replication via WAL shipping. Logical replication causes less updates needed to be shipped, as other updates could be inferred from the replication updates itself.
• Since MySQL replication is decoupled from the physical representation,
  • it is harder to corrupt index records. The common problems are skipped statements / doubly-applied statements.
  • is easier to upgrade (can stream between different versions as long as it still uses the same replication format)
  • applying WAL updates do not block read queries on replicas (true MVCC replication)
• The table below shows how secondary indices are layout on disk and why Postgres suffers from write amplification.

Postgres	InnoDB

[benclmnt]

Figma's Vertical Partitioning

Figma has the largest single managed Postgres deployment. They decided against self-hosting and trying horizontal partitioning solutions. This article focused more on how they do their 2-step migrations: (1) PgBouncer and (2) data.