PostgreSQL

PostgreSQL標榜自己是世界上最先進的開源資料庫。PostgreSQL的一些粉絲說它能與Oracle相媲美，而且沒有那麼昂貴的價格和傲慢的客服。最初是1985年在加利福尼亞大學伯克利分校開發的，作為Ingres資料庫的後繼。PostgreSQL是完全由社群驅動的開源專案。它提供了單個完整功能的版本，而不像MySQL那樣提供了多個不同的社群版、商業版與企業版。PostgreSQL基於自由的BSD/MIT許可，組織可以使用、複製、修改和重新分發程式碼，只需要提供一個版權宣告即可。

MySQL

MySQL聲稱自己是最流行的開源資料庫。LAMP中的M指的就是MySQL。構建在LAMP上的應用都會使用MySQL，如WordPress、Drupal等大多數php開源程式。MySQL最初是由MySQL AB開發的，然後在2008年以10億美金的價格賣給了Sun公司，Sun公司又在2010年被Oracle收購。Oracle支援MySQL的多個版本：Standard、Enterprise、Classic、Cluster、Embedded與Community。其中有一些是免費下載的，另外一些則是收費的。其核心程式碼基於GPL許可，由於MySQL被控制在Oracle，社群擔心會對MySQL的開源會有影響，所以開發了一些分支，比如： MariaDB和Percona。

MySQL與PostgreSQL的對比

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

PostgreSQL相對於MySQL的優勢

1)不僅僅是關係型資料庫

除了儲存正常的資料型別外，還支援儲存：

array，不管是一位陣列還是多為陣列均支援

json(hStore)和jsonb，相比使用text儲存接送要高效很多

json和jsonb之間的區別

jsonb和json在更高的層面上看起來幾乎是一樣的，但在儲存實現上是不同的。

json儲存完的文字，json列會每次都解析儲存的值，它不支援索引，但你可以為查詢建立表示式索引。

jsonb儲存的二進位制格式，避免了重新解析資料結構。它支援索引，這意味著你可以不使用指定的索引就能查詢任何路徑。

當我們比較寫入資料速度時，由於資料儲存的方式的原因，jsonb會比json稍微的慢一點。json列會每次都解析儲存的值，這意味著鍵的順序要和輸入的時候一樣。但jsonb不同，以二進位制格式儲存且不保證鍵的順序。因此，如果你有軟體需要依賴鍵的順序，jsonb可能不是你的應用的最佳選擇。使用jsonb的優勢還在於你可以輕易的整合關係型資料和非關係型資料， PostgreSQL對於mongodb這類的基於文件的資料庫是個不小的威脅，畢竟如果一個表中只有一列資料的型別是半結構化的，沒有必要為了遷就它而整個表的設計採用schemaless的結構。

2)支援地理資訊處理擴充套件

PostGIS 為PostgreSQL提供了儲存空間地理資料的支援，使PostgreSQL成為了一個空間資料庫，能夠進行空間資料管理、數量測量與幾何拓撲分析。在功能上，和MYSQL對比，PostGIS具有下列優勢：

O2O業務場景中的LBS業務使用PostgreSQL + PostGIS有無法比擬的優勢。

3)可以快速構建REST API

PostgREST 可以方便的為任何 PostgreSQL 資料庫提供完全的 RESTful API 服務。

4)支援樹狀結構

支援R-trees這樣可擴充套件的索引型別，可以更方便地處理一些特殊資料。MySQL 處理樹狀的設計會很複雜, 而且需要寫很多程式碼, 而 PostgreSQL 可以高效處理樹結構。

5)有極其強悍的 SQL 程式設計能力

支援遞迴，有非常豐富的統計函式和統計語法支援。

MySQL：支援 CREATE PROCEDURE 和 CREATE FUNCTION 語句。儲存過程可以用 SQL 和 C++ 編寫。使用者定義函式可以用 SQL、C 和 C++ 編寫。

PostgreSQL：沒有單獨的儲存過程，都是通過函式實現的。使用者定義函式可以用 PL/pgSQL(專用的過程語言)、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 編寫。

6)外部資料來源支援

可以把 70 種外部資料來源 (包括 Mysql, Oracle, CSV, hadoop …) 當成自己資料庫中的表來查詢。Postgres有一個針對這一難題的解決方案：一個名為“外部資料封裝器(Foreign Data Wrapper，FDW)”的特性。該特性最初由PostgreSQL社群領袖Dave Page四年前根據SQL標準SQL/MED(SQL Management of External Data)開發。FDW提供了一個SQL介面，用於訪問遠端資料儲存中的遠端大資料物件，使DBA可以整合來自不相關資料來源的資料，將它們存入Postgres資料庫中的一個公共模型。這樣，DBA就可以訪問和操作其它系統管理的資料，就像在本地Postgres表中一樣。例如，使用FDW for MongoDB，資料庫管理員可以查詢來自文件資料庫的資料，並使用SQL將它與來自本地Postgres表的資料相關聯。藉助這種方法，使用者可以將資料作為行、列或JSON文件進行檢視、排序和分組。他們甚至可以直接從Postgres向源文件資料庫寫入(插入、更細或刪除)資料，就像一個一體的無縫部署。也可以對Hadoop叢集或MySQL部署做同樣的事。FDW使Postgres可以充當企業的中央聯合資料庫或“Hub”。

7)沒有字串長度限制

一般關係型資料庫的字串有限定長度8k左右，無限長 TEXT 型別的功能受限，只能作為外部大資料訪問。而PostgreSQL的 TEXT 型別可以直接訪問，SQL語法內建正則表示式，可以索引，還可以全文檢索，或使用xml xpath。MySQL 的各種text欄位有不同的限制，要手動區分 small text, middle text, large text… PostgreSQL 沒有這個限制，text 能支援各種大小。

8)支援圖結構資料儲存

沒有具體使用過，具體可以自己搜尋下。參考連結：https://mp.weixin.qq.com/s/cjor82wgDu5gzDvTYpLDWw

9)支援視窗函式

視窗函式提供跨行相關的當前查詢行集執行計算的能力。僅當呼叫跟著OVER子句的聚集函式，作為視窗函式;否則它們作為常規的聚合函式。視窗也是一種分組，但和 group by 的分組不同。視窗，可以提供分組之外，還可以執行對每個視窗進行計算。可以想象成是group by 後，然後對每個分組進行計算，而不像Group by ，只是單純地分組。MySQL 不支援 OVER 子句, 而PostgreSQL支援。OVER 子句能簡單的解決 “每組取 top 5” 的這類問題。MySQL支援的SQL語法(ANSI SQL標準)的很小一部分。不支援遞迴查詢、通用表表達式(Oracle的with 語句)或者視窗函式(分析函式)。

10)對索引的支援更強

PostgreSQL 的可以使用函式和條件索引，這使得PostgreSQL資料庫的調優非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。對於索引型別：

MySQL：取決於儲存引擎。MyISAM：BTREE，InnoDB：BTREE。

PostgreSQL：支援 B-樹、雜湊、R-樹和 Gist 索引。

InnoDB的表和索引都是按相同的方式儲存。也就是說表都是索引組織表。這一般要求主鍵不能太長而且插入時的主鍵最好是按順序遞增，否則對效能有很大影響。PostgreSQL不存在這個問題。

索引型別方面，MySQL取決於儲存引擎。MyISAM：BTREE，InnoDB：B+TREE。PostgreSQL支援 B-樹、雜湊、R-樹和 Gist 索引。

11)叢集支援更好

Mysql Cluster可能與你的想象有較大差異。開源的cluster軟體較少。複製(Replication)功能是非同步的並且有很大的侷限性。例如，它是單執行緒的(single-threaded)，因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master。

PostgreSQL有豐富的開源cluster軟體支援。plproxy 可以支援語句級的映象或分片，slony 可以進行欄位級的同步設定，standby 可以構建WAL檔案級或流式的讀寫分離叢集，同步頻率和叢集策略調整方便，操作非常簡單。

另外，PostgreSQL的主備複製屬於物理複製，相對於MySQL基於binlog的邏輯複製，資料的一致性更加可靠，複製效能更高，對主機效能的影響也更小。對於WEB應用來說，複製的特性很重要，mysql到現在也是非同步複製，pgsql可以做到同步，非同步，半同步複製。還有mysql的同步是基於binlog複製，類似oracle golden gate,是基於stream的複製，做到同步很困難，這種方式更加適合異地複製，pgsql的複製基於wal，可以做到同步複製。同時，pgsql還提供stream複製。

12)事務隔離做的更好

MySQL 的事務隔離級別 repeatable read 並不能阻止常見的併發更新, 得加鎖才可以, 但悲觀鎖會影響效能, 手動實現樂觀鎖又複雜. 而 PostgreSQL 的列裡有隱藏的樂觀鎖 version 欄位, 預設的 repeatable read 級別就能保證併發更新的正確性, 並且又有樂觀鎖的效能。

13)對於字元支援更好一些

MySQL 裡需要 utf8mb4 才能顯示 emoji 的坑, PostgreSQL 沒這個坑。

14)對錶連線支援較完整

對錶連線支援較完整，MySQL只有一種表連線型別:巢狀迴圈連線(nested-loop),不支援排序-合併連線(sort-merge join)與雜湊連線(hash join)。PostgreSQL都支援。

15)儲存方式支援更大的資料量

PostgreSQL主表採用堆表存放，MySQL採用索引組織表，能夠支援比MySQL更大的資料量。

16)時間精度更高

MySQL對於時間、日期、間隔等時間型別沒有秒以下級別的儲存型別，而PostgreSQL可以精確到秒以下。

17)優化器的功能較完整

MySQL對複雜查詢的處理較弱，查詢優化器不夠成熟，explain看執行計劃的結果簡單。效能優化工具與度量資訊不足。

PostgreSQL很強大的查詢優化器，支援很複雜的查詢處理。explain返回豐富的資訊。提供了一些效能檢視，可以方便的看到發生在一個表和索引上的select、delete、update、insert統計資訊，也可以看到cache命中率。網上有一個開源的pgstatspack工具。

18)序列支援更好

MySQL 不支援多個表從同一個序列中取 id, 而 PostgreSQL 可以。

19)對子查詢支援更好

對子查詢的支援。雖然在很多情況下在SQL語句中使用子查詢效率低下，而且絕大多數情況下可以使用帶條件的多表連線來替代子查詢，但是子查詢的存在在很多時候仍然不可避免。而且使用子查詢的SQL語句與使用帶條件的多表連線相比具有更高的程式可讀性。幾乎任何資料庫的子查詢 (subquery) 效能都比 MySQL 好。

20)增加列更加簡單

MySQL表增加列，基本上是重建表和索引，會花很長時間。PostgreSQL表增加列，只是在資料字典中增加表定義，不會重建表.

MySQL相對於PostgreSQL的優勢

1)MySQL比PostgreSQL更流行

流行對於一個商業軟體來說，也是一個很重要的指標，流行意味著更多的使用者，意味著經受了更多的考驗，意味著更好的商業支援、意味著更多、更完善的文件資料。易用，很容易安裝。第三方工具，包括視覺化工具，讓使用者能夠很容易入門。

2)回滾實現更優

innodb的基於回滾段實現的MVCC機制，相對PG新老資料一起存放的基於XID的MVCC機制，是佔優的。新老資料一起存放，需要定時觸發VACUUM，會帶來多餘的IO和資料庫物件加鎖開銷，引起資料庫整體的併發能力下降。而且VACUUM清理不及時，還可能會引發資料膨脹。

3)在Windows上執行更可靠

與PostgreSQL相比，MySQL更適宜在Windows環境下執行。MySQL作為一個本地的Windows應用程式執行(在 NT/Win2000/WinXP下，是一個服務)，而PostgreSQL是執行在Cygwin模擬環境下。PostgreSQL在Windows下執行沒有MySQL穩定，應該是可以想象的。

4)執行緒模式相比程序模式的優勢

MySQL使用了執行緒，而PostgreSQL使用的是程序。在不同執行緒之間的環境轉換和訪問公用的儲存區域顯然要比在不同的程序之間要快得多。

程序模式對多CPU利用率比較高。程序模式共享資料需要用到共享記憶體，而執行緒模式資料本身就是在程序空間內都是共享的，不同執行緒訪問只需要控制好執行緒之間的同步。

執行緒模式對資源消耗比較少。所以MySQL能支援遠比PostgreSQL多的更多的連線。但PostgreSQL中有優秀的連線池軟體軟體，如pgbouncer和pgpool，所以通過連線池也可以支援很多的連線。

5)許可權設定上更加完善

MySQL在許可權系統上比PostgreSQL某些方面更為完善。PostgreSQL只支援對於每一個使用者在一個數據庫上或一個數據表上的 INSERT、SELECT和UPDATE/DELETE的授權，而MySQL允許你定義一整套的不同的資料級、表級和列級的許可權。對於列級的許可權， PostgreSQL可以通過建立檢視，並確定檢視的許可權來彌補。MySQL還允許你指定基於主機的許可權，這對於目前的PostgreSQL是無法實現的，但是在很多時候，這是有用的。

6)儲存引擎外掛化機制

MySQL的儲存引擎外掛化機制，使得它的應用場景更加廣泛，比如除了innodb適合事務處理場景外，myisam適合靜態資料的查詢場景。

7)適應24/7執行

MySQL可以適應24/7執行。在絕大多數情況下，你不需要為MySQL執行任何清除程式。PostgreSQL目前仍不完全適應24/7執行，這是因為你必須每隔一段時間執行一次VACUUM。

8)更加試用於簡單的場景

PostgreSQL只支援堆表，不支援索引組織表，Innodb只支援索引組織表。

索引組織表的優勢：表內的資料就是按索引的方式組織，資料是有序的，如果資料都是按主鍵來訪問，那麼訪問資料比較快。而堆表，按主鍵訪問資料時，是需要先按主鍵索引找到資料的物理位置。

索引組織表的劣勢：索引組織表中上再加其它的索引時，其它的索引記錄的資料位置不再是物理位置，而是主鍵值，所以對於索引組織表來說，主鍵的值不能太大，否則佔用的空間比較大。

對於索引組織表來說，如果每次在中間插入資料，可能會導致索引分裂，索引分裂會大大降低插入的效能。所以對於使用innodb來說，我們一般最好讓主鍵是一個無意義的序列，這樣插入每次都發生在最後，以避免這個問題。

由於索引組織表是按一個索引樹，一般它訪問資料塊必須按資料塊之間的關係進行訪問，而不是按物理塊的訪問資料的，所以當做全表掃描時要比堆錶慢很多，這可能在OLTP中不明顯，但在資料倉庫的應用中可能是一個問題。

一、 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都沒有問題。

MySQL資料庫比較簡單 網站開發最適合

PSQL基本就是Oracle迷你版，一般人上手較慢。自己考慮

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

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

PostgreSQL不是Oracle公司的，這是相對於MySQL最大的優勢，沒有之一！

MySQL是目前最受歡迎的開源資料庫，PostgreSQL則是我認為最先進的開源資料庫。MySQL是C/C++混合開發，PostgreSQL則是完全的C語言開發，這是在技術方面的差異，接下來我詳細列一下PostgreSQL相對於MySQL優勢，當然其實這些也都能招到，我就列舉幾個比較關鍵的優勢。

PostgreSQL穩定性非常強，InnoDB即使是在斷電這種場景下，PostgreSQL也是相當穩定的，這個MySQL使用者應該是深有體會的，很多估計都經歷過伺服器級別的資料丟失。

MySQL是單儲存引擎，PostgreSQL是多儲存引擎，包括InnoDB、MyISAM等。

刪除臨時表的時候，PostgreSQL語句沒有TEMP、TEMPORARY關鍵字，DROP TABLE通過資料庫連線的排列被刪除。MySQL支援TEMP、TEMPORARY關鍵字，DROP TABLE語句只允許刪除臨時表，要手動刪除。PostgreSQL支援CASCADE選擇刪除表的依賴物件，PostgreSQL的TRUNCATE TABLE支援功能更多。MySQL TRUNCATE TABLE不支援CASCADE食物安全，資料刪除之後就沒辦法回滾了。

PostgreSQL支援多種高階資料型別，比如array，使用者也可以定義型別，MySQL只支援標準型別。PostgreSQL支援布林型，支援IP地址資料型別，支援常量和函式呼叫。PostgreSQL支援JSON和其他NoSQL功能，本機支援XML，允許索引JSON資料，MySQL支援JSON，不過不支援其他的NoSQL功能。PostgreSQL的物件統計功能也很強，這一點MySQL也有差距。

PostgreSQL是多程序、MySQL是多執行緒。PostgreSQL支援大多數命令型別上觸發的觸發器。MySQL是非同步複製，PostgreSQL支援同步、非同步、半同步複製。PostgreSQL要求所有資料必須完全滿足需求，只要出一個錯誤整個資料入庫過程都要失敗，不過MySQL沒這樣的問題。

最後一個優勢，也是我在文章開頭說到的，也是我認為最大的優勢，MySQL誕生於商業公司，現在是讓人生厭的Oracle控制，儘管MySQL現在依然是開源免費的，可是在Oracle手裡總是會讓人擔心。Java在oracle手機搞了些啥大家應該都知道吧，現在Oracle動不動出來噁心噁心大家，反正甲骨文是個不靠譜的公司，隨時想要搞點事情。

PostgreSQL則是誕生於加州伯克利，伯克利還是對計算機技術有過突出貢獻的高校的，PostgreSQL、FreeBSD都是非常有代表性的，這個不會存在像Oracle那麼噁心，所以這個也是一個極大的優勢。

PostgreSQL類似於Oracle的多程序框架，可以支援高併發的應用場景。

如果把Oracle DBA轉到PostgreSQL資料庫上是比較容易的，畢竟PostgreSQL資料庫與Oracle資料庫很相似。

2、 對複雜查詢的處理較弱。（PostgreSQL可解決）

3、 查詢優化器不夠成熟。（PostgreSQL可解決）

PostgreSQL完全支援SQL-92標準，對SQL的支援也很全面，可以支援複雜的SQL查詢。

4、 效能優化工具與度量資訊不足。（PostgreSQL可解決）

PostgreSQL提供了執行計劃和詳細的cost值，可以方便看到SQL的執行效率。

5、 審計功能相對較弱。

6、 安全功能不成熟,沒有使用者組與角色的概念,沒有回收許可權的功能(僅可以授予許可權)。當一個使用者從不同的主機/網路以同樣的使用者名稱/密碼登入之後,可能被當作完全不同的使用者來處理，沒有類似於Oracle的內建的加密功能。

7、 身份驗證功能是完全內建的，不支援LDAP、Active Directory或其它類似的外部身份驗證功能。

8、 Mysql Cluster可能與你想象的有較大差異。

9、 儲存過程與觸發器的功能有限。（PostgreSQL可解決）

PostgreSQL提供了完善的儲存過程和觸發器支援。

10、 垂直擴充套件性較弱。

11、 不支援MPP(大規模並行處理)。（PostgreSQL可解決）

PostgreSQL是類似Oracle資料庫的多程序架構，而不像MySQL是多執行緒的架構，所以能支援MPP。

12、 支援SMP(對稱多處理器),但是如果每個處理器超過4或8個核(core)時,Mysql的擴充套件性表現較差。

13、 對於時間、日期、間隔等時間型別沒有秒以下級別的儲存型別。

14、 可用來編寫儲存過程、觸發器、計劃事件以及儲存函式的語言功能較弱。

15、 沒有基於回滾(roll-back)的恢復功能,只有前滾(roll-forward)的恢復功能。

16、 不支援快照功能。

17、 不支援資料庫鏈(database link)。有一種叫做Federated的儲存引擎可以作為一箇中轉將查詢語句傳遞到遠端伺服器的一個表上,不過,它功能很粗糙並且漏洞很多。

18、 資料完整性檢查非常薄弱,即使是基本的完整性約束，也往往不能執行。（PostgreSQL可解決）

PostgreSQL提供完善的資料完整性檢查機制，支援外來鍵。

19、 優化查詢語句執行計劃的優化器提示非常少。

20、 只有一種表連線型別:巢狀迴圈連線(nested-loop),不支援排序-合併連線(sort-merge join)與雜湊連線(hash join)。（PostgreSQL可解決）

PostgreSQL則支援這些表連線型別。

21、 大部分查詢只能使用表上的單一索引;在某些情況下,會存在使用多個索引的查詢,但是查詢優化器通常會低估其成本,它們常常比表掃描還要慢。（PostgreSQL可解決）

PostgreSQL資料不存在這個問題，假設表T的兩個欄位col1的col2上有兩個索引,idx_1和idx_2，那麼select * from t where col1=:a and col2=:b;查詢時，PostgreSQL資料庫有可能把這個查詢轉化為select * from t where col1=:a intersect select * from t where col2=:b，這樣兩個索引都可以使用上。

22、不支援點陣圖索引(bitmap index)。每種儲存引擎都支援不同型別的索引。大部分儲存引擎都支援B-Tree索引。

23、 管理工具較少,功能也不夠成熟。

24、沒有成熟能夠令人滿意的IDE工具與除錯程式。可能不得不在文字編輯器中編寫儲存過程,並且通過往表(除錯日誌表)中插入記錄的方式來做除錯。

25、 每個表都可以使用一種不同的儲存引擎。（PostgreSQL可解決）

26、 每個儲存引擎在行為表現、特性以及功能上都可能有很大差異。（PostgreSQL可解決）

27、大部分儲存引擎都不支援外來鍵。（PostgreSQL可解決）

28、預設的儲存引擎(MyISAM)不支援事務,並且很容易損壞。（PostgreSQL可解決）

29、最先進最流行的儲存引擎InnoDB由Oracle擁有。（PostgreSQL可解決）

30、有些執行計劃只支援特定的儲存引擎。特定型別的Count查詢,在這種儲存引擎中執行很快,在另外一種儲存引擎中可能會很慢。（PostgreSQL可解決）

PostgreSQL只有一種儲存引擎，所以不存在上面的情況。而PostgreSQL支援完善的事務。

31、執行計劃並不是全域性共享的,,僅僅在連線內部是共享的。

32、全文搜尋功能有限, 只適用於非事務性儲存引擎。 Ditto用於地理資訊系統/空間型別和查詢。（PostgreSQL可解決）

PostgreSQL資料庫支援全文搜尋，支援更多型別的索引，如B-tree,R-tree, Hash, GiST, GIN，R-tree,GIST,GIN索引可用於空間型別和查詢。

33、沒有資源控制。一個完全未經授權的使用者可以毫不費力地耗盡伺服器的所有記憶體並使其崩潰,或者可以耗盡所有CPU資源。

34、沒有整合商業智慧(business intelligence), OLAP **資料集等軟體包。

35、 沒有與Grid Control類似的工具

36、 沒有類似於RAC的功能。如果你問”如何使用Mysql來構造RAC”,只能說你問錯了問題。

37、不支援使用者自定義型別或域(domain)。（PostgreSQL可解決）

PostgreSQL支援豐富的型別，同時也支援自定義型別。

38、 每個查詢支援的連線的數量最大為61。

39、MySQL支援的SQL語法(ANSI SQL標準)的很小一部分。不支援遞迴查詢、通用表表達式（Oracle的with 語句）或者視窗函式（分析函式）。支援部分類似於Merge或者類似特性的SQL語法擴充套件,不過相對於Oracle來講功能非常簡單。（PostgreSQL可解決）

這些PostgreSQL資料庫都支援，如視窗函式。

40、不支援功能列(基於計算或者表示式的列,Oracle11g 開始支援計算列,以及早期版本就支援虛列(rownum,rowid))。

41、不支援函式索引,只能建立基於具體列的索引。（PostgreSQL可解決）

PostgreSQL支援函式索引。

42、不支援物化檢視。

43、不同的儲存引擎之間,統計資訊差別很大,並且所有的儲存引擎支援的統計資訊都只支援簡單的基數(cardinality)與一定範圍內的記錄數(rows-in-a-range)。 換句話說，資料分佈統計資訊是有限的。更新統計資訊的機制也不多。

44、沒有內建的負載均衡與故障切換機制。

45、 複製(Replication)功能是非同步的,並且有很大的侷限性。例如,它是單執行緒的(single-threaded),因此一個處理能力更強的Slave的恢復速度也很難跟上處理能力相對較慢的Master。

46、 Cluster並不如想象的那麼完美。或許我已經提過這一點,但是這一點值得再說一遍。

47、資料字典(INFORMATION_SCHEMA)功能很有限,並且訪問速度很慢(在繁忙的系統上還很容易發生崩潰)。

48、不支援線上的Alter Table操作。

49、 不支援Sequence。（PostgreSQL可解決）

PostgreSQL支援sequence。

50、 類似於ALTER TABLE或CREATE TABLE一類的操作都是非事務性的。它們會提交未提交的事務,並且不能回滾也不能做災難恢復。Schame被儲存在檔案系統上,這一點與它使用的儲存引擎無關。（PostgreSQL可解決）

PostgreSQL不存在這個問題。