壹、
PostgreSQL 的穩定性極強，的確，MySQL 有多種引擎，也確實 Innodb 等引擎在崩潰、斷電之類的災難場景下抗打擊能力有了長足進步，但是，很多 MySQL 用戶都遇到過Server級的數據庫丟失的場景——mysql系統庫是MyISAM的?PG數據庫15分鐘被閃斷四次的前DBA毫無壓力的含笑而過。
二、任何系統都有它的性能極限，在高並發讀寫，負載?近極限下，PG的性能指標仍可以維持雙曲線甚至對數曲線，而
MySQL 明顯出現壹個波峰後下滑。這些曲線在第三方的測試數據中頻繁出現，有興趣的朋友可以 Google 或自己構建壹個測試。
三、在歐美
PG 遠沒有在中國這麽非主流，很多優秀的團隊都在用， 主流的開發語言幾乎都有 PG 的成熟開發接口，這壹點不必有顧慮。像 Python 的 dbapi ，還支持 PG 的異步讀寫，著名的 SQLAlchemy 對PG的壹些特有功能也有支持。
四、PG
多年來在 GIS 領域處於優勢地位，因為它有豐富的幾何類型，實際上不止幾何類型，PG有大量字典、數組、bitmap 等數據類型，通過 SQLAlchemy 這樣的工具，可以大大簡化開發人員的工作。
五、PG
的“無鎖定”特性非常突出，很多 MySQL 需要鎖表（也許是在妳沒有發現的情況下）的操作，PG都可以平滑處理，甚至包括 vacuum 這樣的整理數據空間的操作。這就是PG高並發下優異性能的奧秘。
六、PG
的可以使用函數和條件索引，這使得PG數據庫的調優非常靈活，而這些功能是經過幾十年發展和應用考驗的，絕非某個壹度反復宣稱自己不支持的技術全都是“復雜而無用的”，直到自己支持這些技術為止的數據庫產品可以相比的。
七、PG
對於數據分析師有難以抗拒的魅力，它有極其強悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，例如 /zOqiVYc 這裏的
window 語法。PG 還可以方便的使用 Python、Perl 甚至任何妳喜歡的編程語言寫函數。
八、PG
的有多種集群架構可以選擇，plproxy 可以支持語句級的鏡像或分片，slony 可以進行字段級的同步設置，standby 可以構建WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調整方便，操作非常簡單。有年在騰訊廣州舉辦的 barcamp ，我現場演示，壹次成功。
九、壹般關系型數據庫的字符串有限定長度8k左右，無限長
TEXT 類型的功能受限，只能作為外部大數據訪問。而 PG 的 TEXT 類型可以直接訪問，SQL語法內置正則表達式，可以索引，還可以全文檢索，或使用xml xpath。用PG的話，文檔數據庫都可以省了。
十、PG是BSD類的授權協議，如果妳真的對它有足夠的興趣和動力，可以盡情的閱讀代碼，修改定制。這是出自伯克利校園，歷經數十年錘煉的優秀代碼，是巨大的寶藏。
==================================================================
最後說壹下我感覺
PG 不如 MySQL 的地方。
第壹，MySQL有壹些實用的運維支持，如
slow-query.log ，這個pg肯定可以定制出來，但是如果可以配置使用就更好了。
第二是mysql的innodb引擎，可以充分優化利用系統所有內存，超大內存下PG對內存使用的不那麽充分，
第三是mysql有內存表，這是個被低估的功能。
第四點，MySQL現在允許跳過SQL，在socket上直接調用API，這是個勇敢的嘗試，雖然整個社區用的還不多，但是遇到極端場景，需要榨幹性能的團隊，?得嘗試。