Uber 將 PostgreSQL 的部分數據轉用 MySQL 處理
Uber 原架構使用 Monolith，以單台 PostgreSQL 處理所有資料。
但 Trip 資料量成長太快，單機儲存空間不敷使用，再加上它幾乎耗盡所有 IOPS 資源，促使 Uber 考慮轉用其它架構。
新架構需求如下：
- Operationally robust
- Horizontally scalable both in storage capacity and IOPS
- High write-availability
- Secondary index support
- No downtime for any operation
Uber 特別指出，上述的第五點是現行立即的痛點，因為一旦 PostgreSQL 資料大到某個程度時，任何新增 column 或 index 操作都會造成停機。
他們也研究過 NoSQL 解決方案，但基於過去 NoSQL 的操作經驗以及軟體成熟度，Uber 工程師們對於 NoSQL 是否能夠有效處理 Trip 處理沒有信心。
最後，他們選用了 MySQL / Sharding / Schemaless 成為新 Trip 數據的架構。