先把兩份連結丟出來，一份是 PyPgDay 2013 時由 Uber 的 Evan Klitzke 給的「Migrating Uber from MySQL to PostgreSQL」，原 PDF 連結已經失效 (看起來已經被刪除)，但這個網路年代什麼都可以找到備份... 可以在「Migrating Uber from MySQL to PostgreSQL」取得，但這個網站怪怪的，我另外丟了一份到 Google Docs 上。
另外一份則是同一個人 Evan Klitzke 在 2016 年發表於公司的官方網站上：「Why Uber Engineering Switched from Postgres to MySQL」。
2013 年描述了從 MySQL 換到 PostgreSQL，2016 年同一個人出來則描述了從 PostgreSQL 換到 MySQL 的理由，有種臉腫腫的感覺。
先抓 2013 年的重點，當時分享的目標是要用 PostGIS：
在 2016 年的文章絕口不提 PostGIS，而是提到各種效能問題：花了很長的篇幅講 Non-clustered Index 與 Clustered Index 的設計，以及 Replication 時的頻寬效能差異。
先不管 PostGIS，如果真的是 UPDATE 造成效能問題，那麼不是要朝 sharding 解決嗎，怎麼是換成 MySQL？換到 MySQL 後還是會遇到效能問題啊，你還是要在 application 層上面找出方案啊。
這篇文章看起來更像是內部技術與政治問題掛勾在一起談，因為政治原因而換 MySQL，然後找出技術原因說明換的理由 XDDD
我看到的卻不是 Uber 他們說 UPDATE 有什麼效能問題，而是：
1. PostgreSQL 的 WAL Replication 會消耗大量頻寬
2. PostgreSQL 的 WAL Replication 會讓你在升級 PostgreSQL 版本的時候有很長的 downtime
3. PostgreSQL 的 WAL Replication 有淺在的風險可能讓 index 損毀
而為什麼會有上面 1, 2 點狀況，就是上面提到的 index 如何在硬碟儲存還有 WAL 設計有關
至於第 3 點，是曾經在 9.2 時有個 bug 使 replica 套用錯 WAL 記錄，導致 index 壞掉。Uber 擔心這種 bug 未來可能還會再出現
文章後面也有提到，如果是使用 PostgreSQL 的話，最好使用 pglogical 來做 replication
不過 pglogical 只支援 9.4 以上的版本
I do not see any other database do better (fast and flexible) replication than MySQL does. not even close
以 RTT 來說，通常 PostgreSQL UPDATE 會比 MySQL/InnoDB 快，但當 Table 有著很多 Indexes 又在 udpate-heavy 場景時，情況就不同了。PostgreSQL 會因為頻繁更新相關 Indexes 而更慢甚至有寫次數放大的問題。雖然很多 PostgreSQL 專家提到 HOT updates，但對 Uber 的場景沒太大作用，因為 HOT updates 是有條件限制的。
不過 gslin 前輩舉 2013 年簡報應該是沒有意義的。Uber 高級主任工程師最近已宣稱，MySQL 是用於新的應用，而且他們現在還有很多 PostgreSQL，所以或許可以合理猜測，2013 年簡報提的 PostGIS 應用目前還存在，而且還是 PostgreSQL。
https://news.ycombinator.com/item?id=12217179