PostgreSQL 與 MySQL 相比，優勢何在？

11-25

目前在國內應用PostgreSQL做開發會不會引來性能不佳和後期維護困難的問題？PostgreSQL的前景如何？全球有沒有非常成功的應用案例？

Pg 沒有 MySQL 的各種坑

MySQL 的各種 text 欄位有不同的限制, 要手動區分 small text, middle text, large text... Pg 沒有這個限制, text 能支持各種大小.

按照 SQL 標準, 做 null 判斷不能用 = null, 只能用 is null

the result of any arithmetic comparison with NULL is also NULL

但 pg 可以設置 transform_null_equals 把 = null 翻譯成 is null 避免踩坑

不少人應該遇到過 MySQL 里需要 utf8mb4 才能顯示 emoji 的坑, Pg 就沒這個坑.

MySQL 的事務隔離級別 repeatable read 並不能阻止常見的並發更新, 得加鎖才可以, 但悲觀鎖會影響性能, 手動實現樂觀鎖又複雜. 而 Pg 的列里有隱藏的樂觀鎖 version 欄位, 默認的 repeatable read 級別就能保證並發更新的正確性, 並且又有樂觀鎖的性能. 附帶一個各資料庫對隔離級別的行為差異比較調查: http://www.cs.umb.edu/~poneil/iso.pdf

MySQL 不支持多個表從同一個序列中取 id, 而 Pg 可以.

MySQL 不支持 OVER 子句, 而 Pg 支持. OVER 子句能簡單的解決 "每組取 top 5" 的這類問題.

幾乎任何資料庫的子查詢 (subquery) 性能都比 MySQL 好.

更多的坑:
http://blog.ionelmc.ro/2014/12/28/terrible-choices-mysql/

不少人踩完坑了, 以為換個資料庫還得踩一次, 所以很抗拒, 事實上不是!!!

Pg 不僅僅是 SQL 資料庫

它可以存儲 array 和 json, 可以在 array 和 json 上建索引, 甚至還能用表達式索引. 為了實現文檔資料庫的功能, 設計了 jsonb 的存儲結構. 有人會說為什麼不用 Mongodb 的 BSON 呢? Pg 的開發團隊曾經考慮過, 但是他們看到 BSON 把 ["a", "b", "c"] 存成 {0: "a", 1: "b", 2: "c"} 的時候就決定要重新做一個 jsonb 了... 現在 jsonb 的性能已經優於 BSON.

現在往前端偏移的開發環境里, 用 Pg + PostgREST 直接生成後端 API 是非常快速高效的辦法:
begriffs/postgrest · GitHub
postgREST 的性能非常強悍, 一個原因就是 Pg 可以直接組織返回 json 的結果.

它支持伺服器端腳本: TCL, Python, R, Perl, Ruby, MRuby ... 自帶 map-reduce 了.

它有地理信息處理擴展 (GIS 擴展不僅限於真實世界, 遊戲里的地形什麼的也可以), 可以用 Pg 搭尋路伺服器和地圖伺服器:
PostGIS — Spatial and Geographic Objects for PostgreSQL

它自帶全文搜索功能 (不用費勁再裝一個 elasticsearch 咯):
Full text search in milliseconds with PostgreSQL 不過一些語言相關的支持還不太完善, 有個 bamboo 插件用調教過的 mecab 做中文分詞, 如果要求比較高, 還是自己分了詞再存到 tsvector 比較好.

它支持 trigram 索引.
trigram 索引可以幫助改進全文搜索的結果: PostgreSQL: Documentation: 9.3: pg_trgm
trigram 還可以實現高效的正則搜索 (原理參考 https://swtch.com/~rsc/regexp/regexp4.html )

MySQL 處理樹狀回復的設計會很複雜, 而且需要寫很多代碼, 而 Pg 可以高效處理樹結構:
Scaling Threaded Comments on Django at Disqus
http://www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures

它可以高效處理圖結構, 輕鬆實現 "朋友的朋友的朋友" 這種功能:
http://www.slideshare.net/quipo/rdbms-in-the-social-networks-age

它可以把 70 種外部數據源 (包括 Mysql, Oracle, CSV, hadoop ...) 當成自己資料庫中的表來查詢:
Foreign data wrappers

心動不如行動

Converting MySQL to PostgreSQL

樓上的回答問題很多，這兩個資料庫我都使用過，談談我的看法，這個答案有很大一部分來自於劉鑫的博客（找半天沒找到地址，請讀者自行google）。

一、 PostgreSQL 的穩定性極強， Innodb 等引擎在崩潰、斷電之類的災難場景下抗打擊能力有了長足進步，然而很多 MySQL 用戶都遇到過Server級的資料庫丟失的場景——mysql系統庫是MyISAM的，相比之下，PG資料庫這方面要好一些。
二、任何系統都有它的性能極限，在高並發讀寫，負載逼近極限下，PG的性能指標仍可以維持雙曲線甚至對數曲線，到頂峰之後不再下降，而 MySQL 明顯出現一個波峰後下滑（5.5版本之後，在企業級版本中有個插件可以改善很多，不過需要付費）。
三、PG 多年來在 GIS 領域處於優勢地位，因為它有豐富的幾何類型，實際上不止幾何類型，PG有大量字典、數組、bitmap 等數據類型，相比之下mysql就差很多，instagram就是因為PG的空間資料庫擴展POSTGIS遠遠強於MYSQL的my spatial而採用PGSQL的。

四、PG 的「無鎖定」特性非常突出，甚至包括 vacuum 這樣的整理數據空間的操作，這個和PGSQL的MVCC實現有關係。
五、PG 的可以使用函數和條件索引，這使得PG資料庫的調優非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。
六、PG有極其強悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸！），有非常豐富的統計函數和統計語法支持，比如分析函數（ORACLE的叫法，PG里叫window函數），還可以用多種語言來寫存儲過程，對於R的支持也很好。這一點上MYSQL就差的很遠，很多分析功能都不支持，騰訊內部數據存儲主要是MYSQL，但是數據分析主要是HADOOP+PGSQL（聽李元佳說過，但是沒有驗證過）。
七、PG 的有多種集群架構可以選擇，plproxy 可以支持語句級的鏡像或分片，slony 可以進行欄位級的同步設置，standby 可以構建WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調整方便，操作非常簡單。
八、一般關係型資料庫的字元串有限定長度8k左右，無限長 TEXT 類型的功能受限，只能作為外部大數據訪問。而 PG 的 TEXT 類型可以直接訪問，SQL語法內置正則表達式，可以索引，還可以全文檢索，或使用xml xpath。用PG的話，文檔資料庫都可以省了。
九，對於WEB應用來說，複製的特性很重要，mysql到現在也是非同步複製，pgsql可以做到同步，非同步，半同步複製。還有mysql的同步是基於binlog複製，類似oracle golden gate,是基於stream的複製，做到同步很困難，這種方式更加適合異地複製，pgsql的複製基於wal，可以做到同步複製。同時，pgsql還提供stream複製。
十，pgsql對於numa架構的支持比mysql強一些，比MYSQL對於讀的性能更好一些，pgsql提交可以完全非同步，而mysql的內存表不夠實用（因為表鎖的原因）

最後說一下我感覺 PG 不如 MySQL 的地方。
第一，MySQL有一些實用的運維支持，如 slow-query.log ，這個pg肯定可以定製出來，但是如果可以配置使用就更好了。
第二是mysql的innodb引擎，可以充分優化利用系統所有內存，超大內存下PG對內存使用的不那麼充分，
第三點，MySQL的複製可以用多級從庫，但是在9.2之前，PGSQL不能用從庫帶從庫。
第四點，從測試結果上看，mysql 5.5的性能提升很大，單機性能強於pgsql，5.6應該會強更多.
第五點，對於web應用來說,mysql 5.6 的內置MC API功能很好用，PGSQL差一些。

另外一些：
pgsql和mysql都是背後有商業公司，而且都不是一個公司。大部分開發者，都是拿工資的。
說mysql的執行速度比pgsql快很多是不對的，速度接近，而且很多時候取決於你的配置。
對於存儲過程，函數，視圖之類的功能，現在兩個資料庫都可以支持了。
另外多線程架構和多進程架構之間沒有絕對的好壞，oracle在unix上是多進程架構，在windows上是多線程架構。
很多pg應用也是24/7的應用，比如skype. 最近幾個版本VACUUM基本不影響PGSQL 運行，8.0之後的PGSQL不需要cygwin就可以在windows上運行。
至於說對於事務的支持，mysql和pgsql都沒有問題。

上面說的都很齊全了。
沒有人說FDW(Foreign data wrappers)嗎？那我提一下吧。
第一次看到驚為天人：用統一的SQL，去訪問其他關係資料庫，其他NoSQL資料庫，HBase，甚至是各種格式的文件，操作系統信息，在線數據集。

瞬間爆炸好嗎，各種資料庫大一統萬歲！
舉個栗子，redis_fdw：

我來回答下這個問題吧。我第一份工作是在某兩家大型遊戲公司做數據挖掘的，幹了三年，聽著說是數據挖掘，其實做的最多的我覺得是項目數據分析以及做遊戲的後台報表數據計算框架。大公司因為人才儲備和數據量很大的原因，一般是hadoop+mysql的模式，hadoop計算大量原始數據，然後按維度匯總後的展示數據存儲在mysql供前段web select出來展示。三年後我離職去了一家小型遊戲公司，雖然體量比原來東家小多了，但是遊戲也比較受歡迎，數據也很多。由於人才儲備及成本的原因，小公司並沒有hadoop之類的大數據工具，我這邊搭建這些東西還是使用的mysql，每天凌晨1點左右數據導入算前一天數據報表，需要實時展示的一些數據用python寫的代碼計算。但是mysql做數據報表計算後台最大缺點就是沒有grouping sets和一些窗口函數，替代方案很麻煩而且效率低，還有就是做很多統計數據各種表連接、外連接等等一大堆，不同資料庫之間數據的利用計算。於是我回去查資料偶然間發現了postgresql，短期用了下簡直驚呆了，感覺這資料庫都不要錢還開源，簡直良心。但後面慢慢使用，也發現了一些postgresql的缺點，當然這些缺點只是我作為使用者的感受去說的，可能有寫人不認同。簡單總結下：

優點：
1，單純我使用的感受來說，postgresql的性能應該是遠遠甩mysql三條街的，而且也穩如死狗，相同的數據量複雜計算，postgresql時間一般只有mysql 1/4左右，當然這個時間只是我這邊業務我的使用情況，其他環境可能不一樣，我這邊是多表join，維度聚合等等比較多。還有將大量log文件導入資料庫，也是pgsql快得多。
2，postgresql有grouping sets函數，也是迫使我拋棄mysql第一原因。做報表後台計算，olap/oltp之類的這個函數簡直是剛性需求。沒有grouping sets函數，我感覺做報表後台計算，簡直慘不忍睹。當然pgsql還有挺多很好用的窗口函數之類，用起來真心爽。
3，pgsql對json支持比較好，還有很逆天的fdw功能，就是把別的資料庫的表當自己的用，減少了我這邊很多工作。

4，pgsql的欄位類型支持的多，有很多mysql沒有的類型，但是實際中有時候用到。
缺點：

1，pgsql表名就讓我這種強迫症的人很難受，pgsql對錶名大小寫不敏感的。但是很多時候建表用大寫字母在我看來是很優雅的一種方式。比如手遊行業裡面，創建角色的資料庫你一般得用CreateRole類似這樣的名字吧，不同英文之間大寫標識，但是pgsql會直接給你變成小寫表名，除非你能忍受每次使用這個表加個雙引號，所以我建表就弄成create_role這樣子，但是有些含義較多的會導致表名很長，看著不舒服。當然這算不上大事，但是也是不太方便的一個小細節點。
2，pgsql對語法簡直嚴苛到有時候你認為變態的地步，甚至要為它這個嚴苛的學院派作風做很多代碼修改、預處理。舉個例子，一款手游每天某個日誌會產生幾十G的數據，你要把數據導入進去數據倉庫，一般就是按照欄位名，再指定下分隔符，比如有些公司喜歡用 | 分割欄位等之類，還有的列印json格式。但是你要知道實際生產環境中，伺服器是有很小的幾率（我這邊大概是百萬分之1左右吧）將日誌列印的不規範的，比如簡單的舉個例子角色登錄日誌。一般類似這樣子時間|賬號ID|角色ID|角色名字|等級|登錄IP|機型。但很小的幾率伺服器會將一些欄位丟掉了，比如這個日誌列印成了時間|賬號ID|角色ID|角色名字這樣子，mysql導進去就無所謂，頂多就是這百萬分之一中的這條數據某條數據不完整而已，而且丟掉的一些欄位也不見得重要，但是pgsql直接導入不進去，會直接報錯停掉。每天1000萬行數據，就因為一條列印的不完整，呵呵，對不起，他會直接報錯一條也導入不進去。有些人會說用awk之類預處理，但是數據量大了之後這種預處理也會拖慢效率。還有一個更是頭疼，1000萬裡面有一行將數字類型的等級列印成了字元串的東西，那麼pgsql會非讓你找出這一條刪掉，然後才能將剩下的數據導入進去。mysql就完全沒有這個問題，比如mysql level欄位定義的int類型，幾千萬中有一條數據沒注意列印成字元串，mysql會自己給你轉成0存儲的，不會有任何報錯。
3，pgsql的分區簡直就是災難級別的。使用的繼承之類的概念。建一個主表，然後建立很多小表，繼承到主表，建索引得一個一個在小表上面建立。小表建表的時候指定了分割規則，你導入的時候還是得很傻的按照這個規則去指定那個表導入，pgsql不會對你說，你插入主表，我根據你的建表規則去分配數據。還有它的分表性能差的要死。據說10會內置分表，後面看吧，反正我感覺pgsql的分表慘不忍睹。

總結下來就是，我這邊使用下來，pgsql性能、穩定性會遠強於mysql，功能上也比mysql強大太多，但是真的太學院派風格了，什麼都是感覺在實驗室的環境一樣，對數據對語法嚴苛變態的不近人情，估計得讓寫這個的教授體會下真實的生產環境，他們的產品就不會這麼理想化了。

MySQL如果只有MyISAM一個引擎的話,那你們黑真的也有道理,但問題是InnoDB現在已經是MySQL默認的引擎,而且這個引擎綜合能力很強,能用好這個引擎其實就已經能解決大多數需要資料庫的業務邏輯.在MySQL先佔領市場的前提下,大多數MySQL用戶都是不願意冒風險切換到另一個資料庫的,除非PostgreSQL真的是那個場景上是萬金油.

在數據量極大的時候(大於1億條的級別),InnoDB的B+樹性能的缺陷會暴露,這時MySQL的DBA可能會轉向TokuDB這個第三方開源的MySQL引擎來處理這些大數據.也就是說,MySQL的小用戶,數據量估計連千萬都不到,他們是不可能沒事折騰換資料庫的.MySQL的大用戶,他們熟悉MySQL,他們也更願意使用MySQL,既然TokuDB/Infobright這些第三方引擎能滿足他們的某些需求如大數據存儲和分析,他們也沒有換資料庫的動力.除非PostgreSQL在他們需求上對MySQL有絕對壓倒性優勢.

PostgreSQL真那麼強,其實完全可以像TokuTek(已被Percona收購)那樣,開發一個第三方MySQL存儲引擎在MySQL里挑戰InnoDB嘛,至少TokuDB(分形樹索引)在某些方面證明了自己比InnoDB(B+樹索引)優秀,比如隨機插入性能,數據壓縮效果,大數據存儲和分析.

PG的代碼寫得更好看，研究資料庫看PG代碼更爽。

PostgreSQL再未來與技術上要強於MySQL，但是短時間MySQL的地位是無可動搖的。

PostgreSQL相對於MySQL優勢在於：沒什麼真正大規模互聯網生產環境的應用，偽專家們可以隨便吹。說PG比MySQL坑少的，請用數據和事實說話。

可以看看中國資料庫排行榜和DB-Engine，PG沒什麼人用，談何優勢可言。馬克思經濟學說過沒有使用價值就沒有價值：

中國資料庫排行榜 · 2017年6月 MySQL終超Oracle！！！
DB-Engines Ranking

微信支付商戶系統架構背後的故事 - 騰雲閣 - 騰訊雲

微信支付核心資料庫也是基於 PostgreSQL，還不夠信心？

我之前的一個文檔：
PostgreSQL和MySQL的性能對比實驗 - liyuming0000的專欄 - 博客頻道 - CSDN.NET

裡面是對PG和MySQL資料庫的性能評測數據，希望有用。

搞了大約三年的postgres，中間也分析過mysql。
postgres的優勢在於SQL標準的完備性，對於事務的支持，支持完整的SQL標準，支持事務隔離級別，以及對於數據類型、內置函數、索引的擴展性都比mysql好。postgres的多進程架構提高了系統的穩定性，但是也決定了它不適合在Windows上使用，linux上進程與線程的區別並不大。事實上把postgres改成多線程這件事情很多公司也干過。mvcc的存儲提高了並發性能，但是標記刪除定期vaccum會讓性能抖動。用繼承的方法實現分區表，讓分區表的使用不方便且性能差，這點比不上mysql。
mysql的優勢在於SQL層與存儲層的分離。甚至可以支持每個表使用不同的存儲引擎。

pg 的代碼很好，修改起來是愛恨交織。最好的地方是提供內存分配保護等各種功能非常有用也是容錯比較好的原因吧。pg 開始支持 jason 了，關係型數據和非結構數據可以關聯了！pg cluster 在expedia tripadvisor 上都有好的性能表現！

1. 不會;
2. 好;
3. 有.
對比產品沒有什麼太大的意義.因為你總能用來完成事情. 關鍵是你掌握資料庫的熟練程度.

一路坑坑窪窪地走來 MySQL 之九奇坑，MySQL 5.7 也支持 JSON 了！然而——

當我從 Arch Linux 官方源里安裝了 MySQL 5.7（ Percona）之後，提示我設置了一個臨時密碼，在日誌里。於是啟動 MySQL，並使用臨時密碼登入。然後發現什麼也做不了，除了改密碼。於是改密碼。按慣例生成一個隨機串作為密碼，然而 MySQL 告訴我這密碼強度不夠！於是我嘗試查看 MySQL 默認對密碼的要求，但是！前邊說了，除了改密碼，什麼也做不了！這包括查看它能接受什麼樣的密碼！…………

抱歉，MySQL，我沒有心情看你的源碼。pacman -S postgresql，然後發現世界如此美好。

對了，MySQL 改表結構得全表複製一次！

說到性能，MySQL rollback 很慢的哦！

非常成功的應用案例：CloudFlare 啊！！他們博客（https://blog.cloudflare.com/）除了講他們的產品、講互聯網安全，也講過好幾次 PostgreSQL 的。

當然還有華為、Reddit、Instagram、Disqus 之類的，維基百科上都可以查到的。

兩個資料庫的口號能說明點什麼，pg號稱最先進，MySQL號稱最流行

PG最大的特點就是快。
我做過測試，在默認情況下PG比MYSQL使用INNO引擎的時候速度最高快50倍（1000
~5000萬條記錄）以上。
其次，大數據量情況下非常穩定。在數據量超過千萬條之後，PG查詢速度基本保持穩定。而MYSQL查詢速度會隨著數據量增加迅速下降。
我注意到現在國外很多公司開始更多的傾向於使用PostgreSQL了。

只提一個點：json，hstore和jsonb

提一下兩者對文檔對象的支持，目前JSON的應用很多，但是mysql對json的支持顯然顯得不足，一半公司都是用text來存儲json，然後再應用層解析，這個過程顯然低效的多。
PostgreSQL對文檔對象的支持則明顯完善的多，json，hstore都能支持的很好，最近比較值得注意的是最新版的PostgreSQL中的jsonb類型，完全支持索引，意味著半結構化數據的存儲，混合型存儲的rdbms仍可以高效的支持，這就意味著對於mongodb這類的基於文檔的資料庫是個不小的威脅，畢竟如果一個表中只有一列數據的類型是半結構化的，何必為了遷就它而整個表的設計採用schemaless的結構？

你好摟主，下面是我在網上搜到的，大家來共勉學習下吧：
我們這樣的比較不想僅僅成為一份性能測試報告，因為至少從我個人來看，對於一個資料庫，穩定性和速度並不能代表一切。對於一個成熟的資料庫，穩定性肯定會日益提供。而隨著硬體性能的飛速提高，速度也不再是什麼太大的問題。

這兩個產品都屬於開放源碼的一員，性能和功能都在高速地提高和增強。MySQL AB的人們和PostgreSQL的開發者們都在儘可能地把各自的資料庫改得越來越好，所以對於任何商業資料庫使用其中的任何一個都不能算是錯誤的選擇。

MySQL的背後是一個成熟的商業公司，而PostgreSQL的背後是一個龐大的志願開發組。這使得MySQL的開發過程更為慎重，而PostgreSQL的反應更為迅速。
這樣的兩種背景直接導致了各自固有的優點和缺點。

1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣稱速度是他們追求的主要目標之一，基於這個原因，MySQL在以前的文檔中也曾經說過並不准備支持事務和觸發器。但是在最新的文檔中，我們看到MySQL 4.0.2-alpha已經開始支持事務，而且在MySQL的TODO中，對觸發器、約束這樣的註定會降低速度的功能也列入了日程。但是，我們仍然有理由相信，MySQL將有可能一直保持速度的優勢。
2、MySQL比PostgreSQL更流行，流行對於一個商業軟體來說，也是一個很重要的指標，流行意味著更多的用戶，意味著經受了更多的考驗，意味著更好的商業支持、意味著更多、更完善的文檔資料。
3、與PostgreSQL相比，MySQL更適宜在Windows環境下運行。MySQL作為一個本地的Windows應用程序運行(在 NT/Win2000/WinXP下，是一個服務)，而PostgreSQL是運行在Cygwin模擬環境下。PostgreSQL在Windows下運行沒有MySQL穩定，應該是可以想像的。
4、MySQL使用了線程，而PostgreSQL使用的是進程。在不同線程之間的環境轉換和訪問公用的存儲區域顯然要比在不同的進程之間要快得多。
5、MySQL可以適應24/7運行。在絕大多數情況下，你不需要為MySQL運行任何清除程序。PostgreSQL目前仍不完全適應24/7運行，這是因為你必須每隔一段時間運行一次VACUUM。
6、MySQL在許可權系統上比PostgreSQL某些方面更為完善。PostgreSQL只支持對於每一個用戶在一個資料庫上或一個數據表上的 INSERT、SELECT和UPDATE/DELETE的授權，而MySQL允許你定義一整套的不同的數據級、表級和列級的許可權。對於列級的許可權， PostgreSQL可以通過建立視圖，並確定視圖的許可權來彌補。MySQL還允許你指定基於主機的許可權，這對於目前的PostgreSQL是無法實現的，但是在很多時候，這是有用的。
7、由於MySQL 4.0.2-alpha開始支持事務的概念，因此事務對於MySQL不再僅僅成為劣勢。相反，因為MySQL保留無事務的表類型。這就為用戶提供了更多的選擇。
8、MySQL的MERGE表提供了一個獨特管理多個表的方法。
9、MySQL的myisampack可以對只讀表進行壓縮，此後仍然可以直接訪問該表中的行。

1、對事務的支持與MySQL相比，經歷了更為徹底的測試。對於一個嚴肅的商業應用來說，事務的支持是不可或缺的。
2、MySQL對於無事務的MyISAM表。採用表鎖定，一個長時間運行的查詢很可能會長時間地阻礙對錶的更新。而PostgreSQL不存在這樣的問題。
3、PostgreSQL支持存儲過程，而目前MySQL不支持，對於一個嚴肅的商業應用來說，作為資料庫本身，有眾多的商業邏輯的存在，此時使用存儲過程可以在較少地增加資料庫伺服器的負擔的前提下，對這樣的商業邏輯進行封裝，並可以利用資料庫伺服器本身的內在機制對存儲過程的執行進行優化。此外存儲過程的存在也避免了在網路上大量的原始的SQL語句的傳輸，這樣的優勢是顯而易見的。
4、對視圖的支持，視圖的存在同樣可以最大限度地利用資料庫伺服器內在的優化機制。而且對於視圖許可權的合理使用，事實上可以提供行級別的許可權，這是MySQL的許可權系統所無法實現的。
5、對觸發器的支持，觸發器的存在不可避免的會影響資料庫運行的效率，但是與此同時，觸發器的存在也有利於對商業邏輯的封裝，可以減少應用程序中對同一商業邏輯的重複控制。合理地使用觸發器也有利於保證數據的完整性。
6、對約束的支持。約束的作用更多地表現在對數據完整性的保證上，合理地使用約束，也可以減少編程的工作量。
7、對子查詢的支持。雖然在很多情況下在SQL語句中使用子查詢效率低下，而且絕大多數情況下可以使用帶條件的多表連接來替代子查詢，但是子查詢的存在在很多時候仍然不可避免。而且使用子查詢的SQL語句與使用帶條件的多表連接相比具有更高的程序可讀性。
8、支持R-trees這樣可擴展的索引類型，可以更方便地處理一些特殊數據。
9、PostgreSQL可以更方便地使用UDF(用戶定義函數)進行擴展。

這個問題很難說得清，而
且事實上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的選擇。如何你確定只在MySQL和PostgreSQL中進行選擇，以下規則總是有效的。1、如果你的操作系統是Windows，你應該使用MySQL。
2、如果你對資料庫並不了十分了解，甚至不知道事務、存儲過程等究竟是什麼，你應該使用MySQL。
3、如果你的應用對數據的完整性和嚴肅性要求不高，但是追求處理的高速度。例如是一個論壇和社區，你應該使用MySQL。
4、你的應用是一個嚴肅的商業應用，對數據完整性要求很高。而且你希望對一些商業數據邏輯進行很好的封裝，例如是一個網上銀行，你應該使用PostgreSQL。
5、你的應用處理的是地理數據，由於R-TREES的存在，你應該使用PostgreSQL。
6、你是一個資料庫內核的狂熱愛好者，你甚至希望擁有你自己版本的資料庫，毫無疑問，你必須使用PostgreSQL，沒準下一個PostgreSQL版本中某一個模塊的作者就是你。

以上只是作者從自己的理解盡量客觀公正地評價MySQL和PostgreSQL的優劣。其中的帶有傾向性的意見只代表作者個人觀點，有關這兩個資料庫，歡迎廣大朋友提出自己的看法。

個人感覺，兩者都了解下吧，比如說你想學習資料庫，但是你只是專註於了Oracle，Sybase什麼的資料庫你根本不懂，那對你今後的就業或者搞研究，肯定是有很大的阻礙的，學習資料庫我們不能專註於某一個產品，而是關注整個行業，或許這樣對未來的發展，對資料庫的趨勢才能掌握的很清楚。個人意見，如有不當，還請樓主見諒。謝謝

一、PG相對於MySQL的優勢：
1、在SQL的標準實現上要比MySQL完善，而且功能實現比較嚴謹；
2、存儲過程的功能支持要比MySQL好，具備本地緩存執行計劃的能力；
3、對錶連接支持較完整，優化器的功能較完整，支持的索引類型很多，複雜查詢能力較強；
4、PG主表採用堆表存放，MySQL採用索引組織表，能夠支持比MySQL更大的數據量。
5、PG的主備複製屬於物理複製，相對於MySQL基於binlog的邏輯複製，數據的一致性更加可靠，複製性能更高，對主機性能的影響也更小。
6、MySQL的存儲引擎插件化機制，存在鎖機制複雜影響並發的問題，而PG不存在。

二、MySQL相對於PG的優勢：
1、innodb的基於回滾段實現的MVCC機制，相對PG新老數據一起存放的基於XID的MVCC機制，是佔優的。新老數據一起存放，需要定時觸發VACUUM，會帶來多餘的IO和資料庫對象加鎖開銷，引起資料庫整體的並發能力下降。而且VACUUM清理不及時，還可能會引發數據膨脹；
2、MySQL採用索引組織表，這種存儲方式非常適合基於主鍵匹配的查詢、刪改操作，但是對錶結構設計存在約束；
3、MySQL的優化器較簡單，系統表、運算符、數據類型的實現都很精簡，非常適合簡單的查詢操作；
4、MySQL分區表的實現要優於PG的基於繼承表的分區實現，主要體現在分區個數達到上千上萬後的處理性能差異較大。
5、MySQL的存儲引擎插件化機制，使得它的應用場景更加廣泛，比如除了innodb適合事務處理場景外，myisam適合靜態數據的查詢場景。

三、總體上來說，開源資料庫都不是很完善，商業資料庫oracle在架構和功能方面都還是完善很多的。從應用場景來說，PG更加適合嚴格的企業應用場景（比如金融、電信、ERP、CRM），而MySQL更加適合業務邏輯相對簡單、數據可靠性要求較低的互聯網場景（比如google、facebook、alibaba）。