Spotify switch user database from PostgreSQL to Cassandra
Spotify 轉換的最大原因是：『Single point of failure』(單點故障)。
PostgreSQL 一直以來都沒有成熟的 Master-Master 方案。即使是 Postgres-XC 也是問題一堆，而且跟上新版本的腳步較慢。舉目前最新版 的 Postgres-XC 1.2.1，釋出日期是 2014-04-03，它運行於 PostgreSQL 9.3 之上，而現在 PostgreSQL 最新版是 9.4，連 9.5 都快出來了。
MySQL 的世界則不太一樣，通常用戶煩惱的是，到底要從 MySQL Cluster / Galera Cluster / Tungsten 選用哪套？而且每個工具都能很快追上最新版本，再加上每一套都有大企業運行多年可證實其穩定度。
當遇到 PostgreSQL 的這個問題時，Spotify 怎麼做呢？他們表示，即使有很多台 PostgreSQL 分散世界各地，需要時可以從各地讀取，但是 PostgreSQL 還是只有單台可以寫入 (放在英國倫敦的數據中心)。
一來，通常瓶頸點會發生在此，因為全世界需要寫資料的流量都必須由該台機器處理；二來，『Single point of failure』，不管任何問題，一旦無法連線至此台機器，那麼整個系統都無法寫入。
對於後者，Spotify 舉出 2013 年 9 月海纜斷線事件，導致世界多處無法連到英國倫敦機房而無法寫入資料，造成當週新用戶註冊數顯著下降影響營運。
為了解決這個問題，Spotify 勢必要選用成熟的 Cluster 方案，至於為何選用 Cassandra，官方有在此說明。
原則上就是為了可銜接他們現有的 message system、極佳的擴展性，以及 light transaction 而選用了 Cassnadra。其中極佳的擴展性是現在 MySQL 相對弱勢的，雖然 transaction 是 MySQL/PostgreSQL 的強項，但顯然 Spotify 不需要這麼強大的功能。