2025年：MySQL vs PostgreSQL
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
在 2025 年的當下，MySQL 無論是在功能特性集，質量正確性，性能表現，還是生態與社區上都被 PostgreSQL 拉開了差距，而且這個差距還在進一步擴大中。 今天我們就來對 MySQL 與 PostgreSQL 進行一個全方位的對比，從功能，性能，質量，生態來全方位反映這幾年的生態變化。 功能讓我們先從開發者最關注的東西 —— 功能特性開始說起。 新版本昨天，MySQL 發布了 “創新版本” 9.3[3] 但是看上去和先前的 9.x 一樣，都是些修修補補，看不到什么創新的東西。 搜索尚未發布的 PostgreSQL 18，你能看到無數特性預覽的介紹文章；而搜索 MySQL 9.3，能看到的是社區對此的抱怨與失望。 MySQL 老司機丁奇看完 ReleaseNote 之后表示，《MySQL創新版正在逐漸失去它的意義》，德哥看后寫了 《MySQL將保持平庸》。 對于 MySQL 的 “創新版本”，Percona CEO， Peter Zaitsev 也發三篇《MySQL將何去何從[4]》，《Oracle最終還是殺死了MySQL[5]》，《Oracle還能挽救MySQL嗎[6]》，公開表達了對 MySQL 的失望與沮喪。 在最近幾年，MySQL 在新功能上乏善可陳，與突飛猛進的 PostgreSQL 形成了鮮明的對比。 新功能以數據庫領域最近兩年最為火爆的增量場景 —— 向量數據庫為例。在前兩年的 向量數據庫熱潮中，PostgreSQL 生態里就涌現出了至少六七款向量數據庫擴展（ 在當下，PostgreSQL 生態正在進行著 如火如荼的 DuckDB 縫合大賽 ，
而 MySQL 在這段時間里更新了什么功能呢？一個不支持計算距離與索引的羞辱性 VECTOR 實現[10]；
還有一個企業版專屬的 JS 存儲過程支持（開源版沒有?。?，而這是 PG 15 年前就可以通過 當 MySQL 還局限在 “關系型 OLTP 數據庫” 的定位時， PostgreSQL 早已經放飛自我，從一個關系型數據庫發展成了一個多模態的數據庫，成為了一個數據管理的抽象框架與開發平臺了。 擴展性來自 CMU 的 Abigale Kim 對主流數據庫的可擴展性[11]進行了研究：PostgreSQL 有著所有 DBMS 中最好的 可擴展性（Extensibility），以及其他數據庫生態難望其項背的擴展插件數量 —— 375+，這還只是 PGXN 注冊在案的實用插件，實際生態擴展總數已經破千[12]。至少在開源的 PostgreSQL RDS 發行版 Pigsty 中，就已經開箱即用的提供 405 個擴展的 DEB/RPM 包了。
PostgreSQL 有著一個繁榮的擴展生態 —— 地理空間，時間序列，向量檢索，機器學習，OLAP分析，全文檢索，圖數據庫；這些擴展讓 PostgreSQL 真正成為一專多長的全棧數據庫 —— 單一數據庫選型便可替代各式各樣的專用組件： MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是專用分析數倉與數據湖。
PostgreSQL正在吞噬數據庫世界[13] —— 它正在通過插件的方式，將整個數據庫世界內化其中。“一切皆用 Postgres[14]” 也已經不再是少數精英團隊的前沿探索，而是成為了一種進入主流視野的最佳實踐。 而在新功能支持上，MySQL 卻顯得十分消極 —— 一個應該有大量 Breaking Change 的“創新大版本更新”，不是糊弄人的擺爛特性，就是企業級的特供雞肋，一個大版本就連雞零狗碎的小修小補都湊不夠數。 兼容性除了海量擴展外，PostgreSQL 生態還有更離譜的：兼容功能：你還可以使用擴展或者分支，實現對其他數據庫的兼容。
其中，openHalo 對 MySQL 生態可謂釜底抽薪 —— 在 PG 上直接兼容 MySQL 的線纜協議，這意味著 MySQL 應用可以在不改驅動/代碼的情況下遷移到 PostgreSQL 上來。 另外，OrioleDB 在原生 PostgreSQL 的基礎上，增加了云原生 Undo 存儲引擎，解決了膨脹/XID回卷問題，并實現了 4x 的吞吐量性能。 這并非紙面上的 PR 稿，這些內核/擴展都已經全部在 PostgreSQL 發行版 Pigsty 中作為開箱即用的 RDS 服務直接可用。在這種全能性能怪獸面前，MySQL 將何去何從？ 性能缺少功能也許并不是一個無法克服的問題 —— 對于一個數據庫來說，只要它能將自己的本職工作做得足夠出彩，那么架構師總是可以多費些神，用各種其他的數據積木一起拼湊出所需的功能。 性能劣化的MYSQLMySQL 曾引以為傲的核心特點便是 性能 —— 至少對于互聯網場景下的簡單 OLTP CURD 來說，它的性能是非常不錯的。然而不幸地是，這一點也正在遭受挑戰：Percona 的博文《Sakila：你將何去何從[15]》中提出了一個令人震驚的結論： MySQL 的版本越新，性能反而越差。
根據 Percona 的測試，在 sysbench 與 TPC-C 測試下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出現了平均高達 20% 的下降。而 MySQL 專家 Mark Callaghan 進一步進行了 詳細的性能回歸測試[16]，確認了這一現象：
雞肋的分析性能盡管 MySQL 的優化器在 8.x 有一些改進，一些復雜查詢場景下的性能有所改善，但分析與復雜查詢本來就不是 MySQL 的長處與適用場景，只能說聊勝于無。相反，如果作為基本盤的 OLTP CRUD 性能出了這么大的折損，那確實是完全說不過去的。
而另一方面，PostgreSQL 在 DuckDB 系列擴展與列存擴展的加持下，甚至可以達到比肩 ClickHouse 的分析性能。
Peter Zaitsev 在博文《Oracle最終還是殺死了MySQL[18]》中評論：“與 MySQL 5.6 相比，MySQL 8.x 單線程簡單工作負載上的性能出現了大幅下滑。你可能會說增加功能難免會以犧牲性能為代價，但 MariaDB 的性能退化要輕微得多，而 PostgreSQL 甚至能在 新增功能的同時顯著提升性能[19]”。 穩步提升的PostgreSQL性能MySQL的性能隨版本更新而逐步衰減，但在同樣的性能回歸測試中，PostgreSQL 性能卻可以隨版本更新有著穩步提升。特別是在最關鍵的寫入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。
在 Mark Callaghan 的 性能橫向對比[20] （sysbench 吞吐場景） 中，我們可以看到五年前 PG 11 與 MySQL 5.6 的性能比值（藍），與當下 PG 16 與 MySQL 8.0.34 的性能比值（紅）。PostgreSQL 和 MySQL 的性能差距在這五年間拉的越來越大。
幾年前的業界共識是 PostgreSQL 與 MySQL 在 簡單 OLTP CRUD 場景 下的性能基本相同。然而此消彼長之下，現在 PostgreSQL 的性能已經遠遠甩開 MySQL 了。 PostgreSQL 的各種讀吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些寫場景下的吞吐量更是達到了 200% 甚至 500% 的恐怖水平。 在真實場景中的對比一個有趣的佐證是知名開源項目 JuiceFS[21] 對不同數據庫作為元數據引擎的性能測試。
在這個例子中，我們可以很清晰的看出 MySQL 和 PostgreSQL 在一個真實三方評測中的性能差距。
更多更詳細關于 PostgreSQL 與 MySQL 與 PostgreSQL 的性能評測，我建議各位參考 Mark Callaghan 發表在 Small Datum 上的文章。這是前 Google / Meta 的 MySQL Tech Lead 。 盡管他的主要職業生涯在與 MySQL，Oracle，MongoDB 打交道，并非 PostgreSQL 專家，但他嚴謹的測試方法與結果分析為讀者帶來了許多數據庫性能方面的洞見，比瞎評測的偽專家高到不知道哪里去了。 質量如果新版本只是性能不好，總歸還有辦法來優化修補。但如果是質量出了問題，那真就是無可救藥了。 正確性例如，Percona 最近剛剛在 MySQL 8.0.38 以上的版本（8.4.x, 9.0.0）中發現了一個 嚴重Bug[23] —— 如果數據庫里表超過 1萬張，那么重啟的時候 MYSQL 服務器會直接崩潰！ 一個數據庫里有1萬張表并不常見，但也并不罕見 —— 特別是當用戶使用了一些分表方案，或者應用會動態創建表的時候。而直接崩潰顯然是可用性故障中最嚴重的一類情形。 但 MySQL 的問題不僅僅是幾個軟件 Bug，而是根本性的問題 —— 《MySQL 糟糕的 ACID 正確性》指出，在正確性這個體面數據庫產品必須的基本屬性上，MySQL 的表現一塌糊涂。 權威的分布式事務測試組織 JEPSEN[24] 研究發現，MySQL 文檔聲稱實現的 可重復讀/RR 隔離等級，實際提供的正確性保證要弱得多 —— MySQL 8.0.34 默認使用的 RR 隔離等級實際上并不可重復讀，甚至既不原子也不單調，連 單調原子視圖/MAV 的基本水平都不滿足。這意味著 MySQL 的 RR 隔離等級實際上還不如絕大多數 DBMS 的 RC 隔離等級（MAV）。
MySQL 的 ACID 存在缺陷，且與文檔承諾不符 —— 而輕信這一虛假承諾可能會導致嚴重的正確性問題，例如數據錯漏與對賬不平。對于一些數據完整性很關鍵的場景 —— 例如金融，這一點是無法容忍的。 此外，能“避免”這些異常的 MySQL 可串行化/SR 隔離等級難以生產實用，也非官方文檔與社區認可的最佳實踐；盡管專家開發者可以通過在查詢中顯式加鎖來規避此類問題，但這樣的行為極其影響性能，而且容易出現死鎖。 與此同時，PostgreSQL 在 9.1 引入的 可串行化快照隔離（SSI） 算法可以用極小的性能代價提供完整可串行化隔離等級 —— 而且 PostgreSQL 的 SR 在正確性實現上毫無瑕疵 —— 這一點即使是 Oracle 也難以企及。 李海翔教授在《一致性八仙圖》論文中，系統性地評估了主流 DBMS 隔離等級的正確性，圖中藍/綠色代表正確用規則/回滾避免異常；黃A代表異常，越多則正確性問題就越多；紅“D”指使用了影響性能的死鎖檢測來處理異常，紅D越多性能問題就越嚴重；
不難看出，這里正確性最好（無黃A）的實現是 PostgreSQL SR，與基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通過機制與規則避免并發異常；而 MySQL 出現了大面積的黃A與紅D，正確性水平與實現手法糙地不忍直視。 做正確的事很重要，而正確性是不應該拿來做利弊權衡的。在這一點上，開源關系型數據庫兩巨頭 MySQL 和 PostgreSQL 在早期實現上就選擇了兩條截然相反的道路： MySQL 追求性能而犧牲正確性；而學院派的 PostgreSQL 追求正確性而犧牲了性能。 在互聯網風口上半場中，MySQL 因為性能優勢占據先機乘風而起。但當性能不再是核心考量時，正確性就成為了 MySQL 的致命出血點。 更為可悲的是，MySQL 連犧牲正確性換來的性能，都已經不再占優了，這著實讓人唏噓不已。 完備性SQL 特性與標準支持：PostgreSQL 一直以高度符合 SQL 標準著稱，支持復雜查詢、窗口函數、公共表表達式（CTE）、遞歸查詢、完整的外鍵約束等功能，并且實現了豐富的 SQL/JSON 標準和自定義函數。 MySQL 過去在標準支持上相對落后，但自 8.0 版本起補齊了一些短板：如支持窗口函數和 CTE（包括遞歸 CTE）等，使其在查詢特性上拉近了距離。 但是魔鬼在細節中，許多看上去 “你有我也有” 的功能，內在的實現水準是完全不一樣的。
以 Ecoding 字符編碼與 Collation 排序規則為例，這是很典型的企業級應用需要的多語言關鍵特性。PostgreSQL 在 ICU 支持下提供了 42 種字符集編碼與 815 種排序規則支持，覆蓋了幾乎你能想象到的一切排序方法。 而 MySQL 在基本上就只有 五種字符集和幾十個基于此的排序規則[26]。這是一個很好的微觀細節樣本，體現出 PostgreSQL 與 MySQL 在細節上的用心程度與差異。 生態對一項技術而言，用戶的規模直接決定了生態的繁榮程度。瘦死的駱駝比馬大，爛船也有三斤釘。 MySQL 曾經搭乘互聯網東風扶搖而起，攢下了豐厚的家底，它的 Slogan 就很能說明問題 —— “世界上最流行的開源關系型數據庫”。 開發者MySQL 的 Slogan 是 “世界上最流行的開源關系型數據庫”，但似乎現在并沒有多少權威數據能支持這個說法。 相反的是，在 StackOverflow 過去八年的全球開發者調研中，我們可以觀察到 PostgreSQL 在開發者中的使用率節節攀升，并于 2023 年第一次超過 MySQL ，成為最流行的數據庫。
從各個角度上來看，MySQL “最流行” 的稱號已經名不副實了。而 PostgreSQL 已經成為這幾年最流行的數據庫，并且不需要不需要開源/關系型等定語修飾。
在需求度，喜愛度，流行度上，PostgreSQL 在過去八年的變化趨勢非常明顯：
在最為活躍的前端開發者生態中，PostgreSQL 已經憑借豐富的功能特性，以壓倒性優勢成為最受歡迎的的數據庫。例如，在 Vercel 支持的 7 款存儲服務上，四個是 Postgres 衍生（Neon,Supabase,Nile,Gel），兩個 Redis 衍生，一個 DuckDB ，完全不見 MySQL 的蹤影。
而根據 DBDB.io 的統計數據，派生自 PostgreSQL 的數據庫項目也顯著超過了 MySQL。 廠商最直觀的數據： AWS RDS 上 PostgreSQL 實例的數量與 MySQL 實例的數量已經達到了 6:4 ，也就是 PG 實例的數量已經比 MySQL 要多 50% 了。 即使是在 MYSQL 曾經占據壓倒性優勢的中國大陸，來自阿里云 RDS 實例數的樣本也說明 MYSQL:PG 從前幾年的 10:1 快速縮小到 5:1，并且增量上 PG 也已經超過 MYSQL 了。 從商業角度看，云廠商已經將重注下在了 PostgreSQL，而非 MySQL 上。 例如 AWS RDS （MySQL+PG）產品經理是 PostgreSQL 社區核心組成員 Jonathan Katz，也是最近 pg/pgvector 在向量數據庫領域崛起關鍵推手之一。 最近的 Aurora 新品分布式 DSQL 只有 PostgreSQL 兼容，沒搞 MySQL 的，而以前這種事從來都是 MySQL 優先，這次似乎直接放棄 MYSQL 支持了。 Google 的 OLTP 數據庫 AlloyDB 也選擇完全兼容 PostgreSQL ，并且也在 Spanner 中提供 PostgreSQL 了。 國內云廠商例如阿里云也選擇押寶 PostgreSQL 分支路線，例如獲得信創資質認證的 PolarDB 2.0 （Oracle）兼容其實就是基于 PolarDB PG 二次分枝的版本。 資本市場最近的 大額融資紀錄，也基本發生在 PostgreSQL 生態中。
而 MySQL 生態屈指可數，基本只有 SingleStore，TiDB ，而原本生態中全村的希望 MariaDB 則一路跌的干脆直接要退市私有化了。 大型用例對于制造業，金融，非互聯網場景，PostgreSQL 憑借其強大的功能特性與正確性，已經成為了許多大型企業的首選數據庫。 例如在我任職 Apple 期間，我們部門使用 PostgreSQL 存儲所有工廠的工業互聯網數據并進行數據分析。包括我們部門在內的許多項目都在使用 PostgreSQL，甚至有一個內部的社區與興趣小組。 大型互聯網公司受制于歷史路徑依賴于慣性仍然保留有大量 MySQL，但也基本開始兩頭下注，很多 PostgreSQL 的支持者都是微軟，AWS，Apple，Google 這樣的大公司。而在新興創業公司中，PostgreSQL 更是已經取得顯著優勢。 例如，Cursor、 Dify、Notion 這樣的 AI 新寵都默認使用 PostgreSQL 作為元數據存儲。支付明星企業 Strip 也在一些系統中使用 PostgreSQL 進行分析。 Cloudflare 與 Vercel 的內部系統大量使用了 PostgreSQL， Node.js 社區項目也明顯對 PostgreSQL 有偏好（例如 Prisma ORM 對PG 支持更完善）。很多開源新項目都默認選擇 PostgreSQL 作為其首選數據庫 —— 如果不是唯一選擇的話。 MYSQL 到底怎么了？究竟是誰殺死了 MySQL，難道是 PostgreSQL 嗎？Peter Zaitsev 在《Oracle最終還是殺死了MySQL[27]》一文中控訴 —— Oracle 的不作為與瞎指揮最終害死了 MySQL；并在后續《Oracle還能挽救MySQL嗎[28]》一文中指出了真正的根因： MySQL 的知識產權被 Oracle 所擁有，它不是像 PostgreSQL 那種 “由社區擁有和管理” 的數據庫，也沒有 PostgreSQL 那樣廣泛的獨立公司貢獻者。不論是 MySQL 還是其分叉 MariaDB，它們都不是真正意義上像 Linux，PostgreSQL，Kubernetes 這樣由社區驅動的的原教旨純血開源項目，而是由單一商業公司主導。 比起向一個商業競爭對手貢獻代碼，白嫖競爭對手的代碼也許是更為明智的選擇 —— AWS 和其他云廠商利用 MySQL 內核參與數據庫領域的競爭，卻不回饋任何貢獻。于是作為競爭對手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也參與進來搞云 —— 僅僅只關注它自己的 MySQL heatwave 云版本，就像 AWS 僅僅專注于其 RDS 管控和 Aurora 服務一樣。在 MySQL 社區凋零的問題上，云廠商也難辭其咎。 總結盡管我是 PostgreSQL 的堅定支持者，但我也贊同 Peter Zaitsev 的觀點： “如果 MySQL 徹底死掉了，開源關系型數據庫實際上就被 PostgreSQL 一家壟斷了，而壟斷并不是一件好事，因為它會導致發展停滯與創新減緩。PostgreSQL 要想進入全盛狀態，有一個 MySQL 作為競爭對手并不是壞事” 至少，MySQL 可以作為一個鞭策激勵，讓 PostgreSQL 社區保持凝聚力與危機感，不斷提高自身的技術水平，并繼續保持開放、透明、公正的社區治理模式，從而持續推動數據庫技術的發展。
MySQL 曾經也輝煌過，也曾經是“開源軟件”的一桿標桿，但再精彩的演出也會落幕。MySQL 正在死去 —— 更新疲軟，功能落后，性能劣化，質量出血，生態萎縮，此乃天命，實非人力所能改變。而 PostgreSQL ，將帶著開源軟件的初心與愿景繼續堅定前進 —— 它將繼續走 MySQL 未走完的路，寫 MySQL 未寫完的詩篇。 References
閱讀原文：https://mp.weixin.qq.com/s/NTd9_QRJRIu_XLbZ1zv7KA 該文章在 2025/4/17 18:02:19 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
?
