MySQL贏了2000s，PostgreSQL贏得2020s，誰將贏得AI時代？——數據庫選型的三要素分析法

對于數據庫從業者來說， 2026年，只有一個重要的問題：誰將贏得AI時代的數據庫市場？

這不是技術特性的比拼，也不是營銷預算的較量。我認為決定數據庫勝負的是三個要素：技術套件、標桿案例、生態系統。MySQL用LAMP + Facebook + Stack Overflow贏得2000s。PostgreSQL用Heroku/Vercel + Instagram + 云廠商贏得2020s。都是三要素在起作用。

AI時代誰會贏？除了騙子， 沒有人敢說自己已經有答案了。但是我們可以從歷史中借鑒一些經驗，抽取通用的理論，然后用它來幫助我們撥開一些迷霧。畢竟，時間不等人，窗口期就是2026年了。

為什么MySQL贏了2000s

MySQL主宰2000s不是因為功能特性比PostgreSQL好，而是因為滿足了三要素。

要素一：技術套件 - LAMP的深度綁定

LAMP = Linux + Apache + MySQL + PHP。這不只是四個軟件的打包，而是深度技術集成：PHP有原生MySQL驅動（mysql_connect, mysqli），Apache有針對PHP+MySQL優化的模塊，主機提供商的基礎設施假設你用LAMP，教程和文檔默認LAMP技術棧。

更重要的是分發渠道：2000s的共享主機時代，70%的主機提供商（Bluehost, HostGator等）提供cPanel一鍵安裝器（Softaculous, Fantastico）。你不需要懂技術，點一下按鈕，WordPress/Joomla就裝好了，MySQL也跟著來了。那時候建網站的人，很多是小企業主，不是工程師。他們根本不知道"選擇數據庫"這件事，主機提供商替他們做了決定。

你不是"選擇MySQL"，你是"選擇LAMP"，MySQL隨之而來。

即使你想用PostgreSQL，共享主機提供商也不支持。為什么？因為PostgreSQL在2000s有關鍵技術差距：MySQL早在2000s初就有主從復制，而PostgreSQL直到2010年（9.0版本）才有流式復制——整整10年的技術代差。Web 2.0時代，復制是擴展web應用的必需品。技術不成熟 + 主機提供商不支持，PostgreSQL連進入比賽的資格都沒有。

要素二：標桿案例 - Facebook證明MySQL能支撐規模

2000s最大的技術焦慮是：這個數據庫能不能支撐規模？

Facebook用MySQL擴展到10億用戶，這個故事消除了所有擔憂。不只是Facebook，還有GitHub, Twitter（早期架構），中國的淘寶、騰訊、百度，都用MySQL支撐大規模應用。這些公司的工程博客、技術大會演講，把MySQL擴展經驗變成公開知識。

標桿案例的作用不只是技術可行性證明，更重要的是降低決策成本。創業公司創始人拿著商業計劃書找投資人，說"我們用MySQL，Facebook也用MySQL"，投資人立刻理解。說"我們用PostgreSQL，因為ACID實現更完整"，得花30分鐘解釋為什么不用行業標準。工程師跟老板提方案，說"行業標準"四個字就夠了，不需要寫詳細的技術評估報告。

更妙的是政治安全：失敗了可以說"我們遵循了行業最佳實踐"（責任分散），成功了是我的功勞（功勞集中）。理性的啟發式策略。

標桿案例還創造人才池：大公司用MySQL，工程師就學MySQL，人才市場自然形成。招聘時寫"MySQL DBA"，簡歷一堆；寫"PostgreSQL DBA"，簡歷寥寥。

要素三：生態系統 - 讓技術債變得可以容忍

MySQL有很多設計問題：默認字符集是latin1不是UTF-8，真正的UTF-8叫utf8mb4；TIMESTAMP只支持到2038年；DDL不支持事務；GROUP BY可以選擇非聚合列（違反SQL標準）。PostgreSQL粉絲最愛列舉這些缺陷。

但生態系統讓這些問題變得可以容忍。

MySQL的Stack Overflow問題數量是PostgreSQL的5倍。遇到字符集問題？網上有成千上萬篇utf8mb4教程，告訴你怎么改配置、怎么遷移數據、怎么避免踩坑。復制延遲問題？有Vitess、Orchestrator等第三方工具幫你管理。沒有DDL事務？最佳實踐已經演化：用工具做模式遷移，加版本控制，先在測試環境測試。中文社區特別活躍，任何問題都能找到中文解答。

生態系統的存在，讓工程師不需要成為數據庫專家（被迫的），可以專注業務邏輯。PostgreSQL技術上再好，遇到問題找不到答案，就得啃官方文檔、讀源代碼、去郵件列表問問題，時間成本高太多。

更強的鎖定來自WordPress：WordPress只支持MySQL，占全球網站的40%。這些網站永遠不會遷移到PostgreSQL，遷移成本太高：不只是數據，還有插件、主題、運維流程。數據庫遷移項目只有17%能按時按預算完成（Gartner數據），30%成本超支，平均4小時停機時間損失$28k。有這個生態系統，誰還冒險遷移？

**三要素的正反饋循環：**LAMP技術套件帶來大量用戶 → 用戶中產生Facebook/BAT這樣的標桿案例 → 標桿案例吸引更多創業公司模仿 → 用戶貢獻Stack Overflow答案、寫教程、開發工具 → 生態系統降低使用門檻 → 更多用戶選擇MySQL。

MySQL主宰2000s，三要素缺一不可。

為什么PostgreSQL贏得2020s

PostgreSQL的崛起用相同的三要素，但機制完全不同。

要素一：技術套件 - 從具名技術棧到平臺默認

LAMP時代的特征是具名技術棧捆綁。它有明確的縮寫：LAMP, WAMP, MAMP。開發者主動選擇，說"我們是LAMP團隊"。技術棧是完整的，從操作系統到應用層。分發渠道是共享主機的cPanel一鍵安裝。

云時代的機制變了。Rails用PostgreSQL，但沒有"RHP Stack"這個名字。開發者被動繼承：選擇框架/平臺，數據庫自動跟隨。不包含操作系統層，因為基礎設施已經抽象化（這是云的本質）。分發渠道是平臺默認 + 啟動模板。

平臺默認配置更強大，因為它是隱形標準化。

Heroku是第一個證明這個機制的平臺。2007年創立時，Heroku只提供PostgreSQL——不是選擇，是約束。你要用Heroku部署Rails，就必須用PostgreSQL。DATABASE_URL環境變量約定成為Rails社區標準，git push heroku main的部署流程和PostgreSQL深度集成。開發者根本沒有"選擇"這個步驟，PostgreSQL就在那里了。結果：Heroku管理了2百萬+個PostgreSQL數據庫。

Vercel把這個機制推向極致。2023年推出Vercel Postgres，背后是Neon PostgreSQL（大多數開發者不知道）。當你運行create-next-app，啟動模板已經配置好PostgreSQL + Prisma。Next.js的官方教程和文檔假定你用PostgreSQL。npx vercel db init自動部署PostgreSQL。開發者說"我用Next.js"時，PostgreSQL是隱含的。

平臺默認配置比具名技術棧捆綁更強大，因為它的摩擦更低。LAMP時代，你得主動說"我選擇LAMP"，這是個顯性決策。Vercel時代，數據庫選擇直接消失了——你說"我用Next.js"時，根本不會提數據庫，但PostgreSQL已經在那里了。決策疲勞降到零。

更妙的是品牌推廣的成本。LAMP需要一個朗朗上口的縮寫，需要營銷推廣"LAMP技術棧"這個概念。平臺默認配置不需要，它搭Next.js或Rails的便車——框架火了，數據庫自然跟著火。這是隱形的標準化，比顯性的品牌推廣更有效。

鎖定也更強。LAMP時代你可以只換MySQL，其他保留。平臺默認配置時代，切換數據庫意味著放棄平臺的優化：Vercel為PostgreSQL優化的連接池、監控面板、部署流程，你換成MySQL就都沒了。商業設計使然。

PostgreSQL不是靠功能特性贏的。它贏在成為新一代平臺的默認選擇，而開發者對此甚至沒有意識。

要素二：標桿案例 - Instagram和云廠商的隱性背書

MySQL時代的標桿案例是"證明能擴展"：Facebook擴展到10億用戶，證明MySQL能支撐大規模負載。這是防御性的證明——消除擔憂。

PostgreSQL時代的標桿案例是"證明夠現代"：Instagram用PostgreSQL從零擴展到數億用戶，但重點不是"它能擴展"，而是"精英工程團隊選擇了它"。Apple, Spotify, Reddit用PostgreSQL。中國新一代公司像探探也用PostgreSQL。這些案例傳遞的信息不是"它能用"，而是"前瞻性公司用它"。

更強大的是云廠商的隱性背書。AWS、Google Cloud、Azure都大量投資PostgreSQL托管服務。Stack Overflow調查顯示58%的專業開發者用PostgreSQL，被評為"最受推崇"數據庫。這創造了認知：PostgreSQL是未來的選擇，MySQL是遺留技術。

要素三：生態系統 - 云廠商 + 經濟激勵

三大云廠商（AWS, Google, Azure）都把PostgreSQL作為戰略重點。新版本PostgreSQL 17發布幾個月內，云廠商的托管服務就更新了。MySQL的更新？慢得多，因為Oracle的授權讓云廠商不舒服。商業問題。

經濟激勵也在發揮作用。PostgreSQL是BSD許可證，完全免費；MySQL商業使用要付費（$2k-5k/年）。更顯著的是人才市場：PostgreSQL DBA平均年薪$133k，MySQL DBA $73k——接近2倍差距。這告訴年輕工程師該學什么。

Supabase打開了新的分發渠道。它是"開源Firebase替代方案"，完全構建在PostgreSQL上。后端即服務市場，Firebase用NoSQL，Supabase用PostgreSQL——想要Firebase體驗但要關系型數據庫的開發者，自然選PostgreSQL。

技術成熟度也終于趕上了。PostgreSQL 2010-2024持續改進：流式復制（2010），JSONB（2014），原生分區，并行查詢。到新技術套件形成時（Heroku/Vercel），技術已經就緒。生態系統現在幫PostgreSQL克服剩余的問題，比如水平擴展的復雜性。

三要素的新循環： 平臺默認配置帶來新用戶 → 新用戶中有Instagram/Apple這樣的標桿案例 → 標桿案例吸引云優先創業公司 → 云廠商投資托管服務 → 經濟激勵吸引人才 → 生態系統持續成長。

MySQL用LAMP + Facebook + Stack Overflow贏得2000s。PostgreSQL用Heroku/Vercel + Instagram/OpenAI + 云廠商贏得2020s。機制相同，但更隱蔽、更強大。

誰將贏得AI時代？

理解了三要素，就能預測：下一個贏家必須滿足三個條件。

條件一：成為AI編程套件的一部分

不能只追求兼容性（那是防守），要找到下一個大趨勢。

傳統路徑是綁定新興語言/框架（Rust? Deno/Bun?）。但這些都是漸進式創新，不是范式轉變。風險：投入巨大，可能市場太小。

真正的機會在AI編程套件。不是愚蠢的向量數據庫——那是為AI應用數據服務的，pgvector已經做了。真正的機會是為AI編程工作流設計的數據庫。

問題重新定義：AI編程者（像我）每天寫代碼，什么數據大語言模型管不好？

大語言模型擅長代碼生成、文本處理、模式匹配。但不擅長結構化數據持久化、事務一致性、復雜關系查詢、模式演進追蹤、數據完整性約束——這些正是數據庫應該補充的地方。

可能的AI編程套件長什么樣？AI編程助手（Claude Code, Cursor等）+ 針對AI-人類協作優化的數據庫 + 管理"大語言模型不該碰的數據"的工具。比如會話狀態、用戶偏好、結構化配置、審計日志——這些數據需要強一致性，不能讓大語言模型隨意修改。

為什么這是真正的機會？因為AI編程是范式轉變，現在的數據庫都為人類編程者設計。AI + 人類協作工作流需要不同的數據管理模式。誰搶到先發優勢建立這個技術套件，誰就是下一個PostgreSQL。

賭對了 = Heroku的PostgreSQL。賭錯了 = 無人問津。

條件二：打造代表未來的標桿案例

標桿案例必須是創新的，能代表未來。Facebook對MySQL的價值在于證明"能支撐規模"，這是2000s的焦慮。未來的焦慮是什么？AI工作流能不能可靠運行，會話狀態能不能一致管理，AI生成的數據能不能正確存儲。

Supabase和OpenAI合作，為ChatGPT插件提供PostgreSQL + pgvector的知識庫方案。這不是偶然：AI需要既能做語義搜索（pgvector），又能保證事務一致性（PostgreSQL）的數據庫。這就是AI時代的標桿案例：不是證明"能擴展"（那是上個時代的問題），而是證明"能同時處理結構化數據和向量搜索"。

這個案例傳遞了信號：PostgreSQL理解AI時代的需求。其他數據庫廠商如果想贏得AI時代，需要類似的案例——某個知名AI產品公開選擇某個數據庫，并解釋原因。沒有這樣的標桿案例，技術再好也難推廣，就像Mnesia有技術優勢，但除了Klarna誰在用？

條件三：加入既有生態系統

與其從零建立生態系統，不如加入既有生態系統——就像AI編程生態系統。

AI編程工具（Claude Code, Cursor）已經有龐大的用戶群。如果某個數據庫成為這些工具的默認選擇，就能立即獲得生態系統：開發者社區、教程內容、工具集成。這比從零積累云廠商支持、對象關系映射、監控工具要快得多。關鍵是找對生態系統，加入進去，而不是自己造一個。

三要素理論的驗證

三要素理論不僅能解釋MySQL和PostgreSQL過去三十年的歷史，還可以用于解釋很多DB選型現象。

用三要素理論看中國數據庫廠商的Oracle兼容性策略

OceanBase、PolarDB、GaussDB都大量投入Oracle兼容性，不只是SQL方言，還有PL/SQL、包、存儲過程的完整模擬。為什么？

因為中國企業（銀行、電信、政府）的Java + Oracle組合是既定技術套件。Oracle兼容讓企業無需改代碼，中間件繼續運作，運維流程不變。Oracle的龐大存量用戶就是現成的標桿案例，"跟Oracle一樣"就是最好的證明。DBA團隊的知識直接復用，培訓成本幾乎為零。

"借用"Oracle的三要素，比創造全新技術套件/標桿/生態要快得多。理性的防守策略。

用三要素理論看具體的項目架構決策

馬工本人在一個新項目中用三個數據庫：S3存業務對象，PostgreSQL存請求狀態，DynamoDB存編排服務狀態。為什么不統一用PostgreSQL？

因為編排服務用AWS Step Functions，而Step Functions + DynamoDB是集成套件。開發工具包優化、權限配置簡單、監控默認集成。用PostgreSQL要自己寫集成代碼、配網絡安全組、設連接池。單獨換數據庫不劃算，只有換整個套件才合理。但是用Temporal替換Step Functions，不是DB層面的決策。

技術套件的綁定力，在微觀層面同樣成立。

用三要素理論看BigQuery在北歐的流行

BigQuery在北歐的流行程度遠超其他地區。Validio對北歐獨角獸和高速成長公司的調研顯示，BigQuery采用率達45%，遠超Snowflake和Redshift。全球范圍內，BigQuery與競爭對手的差距很小甚至落后，但在北歐市場，BigQuery占據統治地位。為什么？三要素完美解釋。

標桿案例：從Spotify到金融科技三巨頭。Spotify把整個大數據平臺從2500節點的Hadoop集群遷移到Google Cloud Platform，用BigQuery替代Hive，開源了Scio（Scala + Apache Beam API）處理每天超過1萬億條事件。Spotify不只是用BigQuery，還公開分享架構演進，工程博客詳細記錄遷移過程。這創造了標桿效應。

更強的信號來自金融科技公司的成功退出：Zettle（2018年被PayPal以22億美元收購）、Tink（2021年被Visa以18億歐元收購）都用BigQuery作為數據倉庫。King（動視暴雪子公司）、IKEA也在用。當北歐最成功的科技公司都用BigQuery，并且被國際巨頭高價收購，這傳遞了強烈信號："這個技術棧能支撐獨角獸成長和成功退出"。

技術套件：跨云架構范式。真正有意思的不是"全用GCP"，而是一個跨云的架構范式：AWS處理業務邏輯和實時流，BigQuery做分析和報表。

看Tink的做法：用AWS Kinesis采集支付和賬戶數據流，落到S3數據湖，然后用Airflow編排轉換任務，最后在BigQuery里跑SQL做分析。

Zettle也是類似思路。交易系統跑在AWS EC2和RDS上，600GB的主數據庫處理實時支付。但商戶分析報表？全在BigQuery。實時交易需要低延遲，AWS的VPC和RDS能保證；歷史數據分析需要掃描大量記錄，BigQuery的列式存儲和并行查詢更快。各取所長。

這個跨云模式幾乎成了北歐金融科技的標準范式。不是被GCP營銷說服，而是理性選擇：AWS運行業務邏輯，BigQuery做數據分析。當Zettle和Tink都被高價收購，這個架構就被驗證了。后來的創業公司不需要再評估——直接復制，招這兩家出來的工程師，照著已驗證的最佳實踐做。

生態系統：人才市場與工具棧標準化。Spotify培養了大批BigQuery專家，這些人離職后去創業公司、咨詢公司，帶著BigQuery技能。招聘市場形成：職位描述寫"BigQuery經驗優先"，候選人簡歷里寫"Spotify數據工程師，精通BigQuery"。Tink的技術負責人說得很直白，選BigQuery是因為"需要最少的工程資源，同時提供最高的生產力".

更重要的是工具棧的標準化。Validio的調研顯示，北歐數據團隊有明確的技術棧共識：Airflow做編排，dbt做轉換，BigQuery做倉庫，Looker做可視化，Postgres做事務數據庫，Kafka做流處理。這六個工具成為事實標準。新公司不需要重新評估技術選型——直接用這個棧，在LinkedIn上搜索"Stockholm + BigQuery + Airflow"就能找到候選人，Stack Overflow上的問題都有北歐工程師回答過。

這個生態系統的網絡效應極強：更多公司用 → 更多工程師學 → 更多教程和最佳實踐 → 更容易招人 → 更多公司用。其他歐洲地區沒有這個效應，即使想用BigQuery也缺少本地支持。

BigQuery的明顯劣勢

有意思的是，BigQuery有很多明顯的技術劣勢：

• 沒有索引

  。傳統數據庫依賴索引優化查詢，BigQuery強制全表掃描，只能靠列式存儲和分區緩解

• 沒有主鍵約束

  。數據完整性完全靠應用層保證，插入重復數據不會報錯

• SQL方言怪異

  。嵌套和重復字段的語法跟標準SQL差異巨大，學習曲線陡峭

• 成本不可預測

  。按掃描數據量計費，一個寫錯的JOIN可能掃描TB級數據，賬單暴漲

• 供應商鎖定

  。沒有真正的遷移路徑，數據和查詢都深度綁定GCP

這些不是小問題。任何理性的技術評估都會列出這些風險。但在北歐，這些劣勢被三要素完全壓制。Spotify每天處理1萬億事件，Zettle被PayPal以22億美元收購，Tink被Visa以18億歐元收購——都用BigQuery。這就夠了。技術套件已經建立（AWS + BigQuery跨云范式），人才市場已經形成（Airflow + dbt + BigQuery標準棧），沒人在乎索引或主鍵約束。

從Spotify一家公司，擴散到整個北歐科技圈，BigQuery采用率45%（全球其他地區遠低于此）。標桿案例（成功退出） → 技術套件鎖定（跨云架構范式） → 生態系統自增長（工具棧標準化）。三要素在地區層面同樣成立，并且強大到可以讓明顯的技術劣勢變得無關緊要。

結論

MySQL用LAMP + Facebook + Stack Overflow贏得2000s。PostgreSQL用Heroku/Vercel + Instagram + 云廠商贏得2020s。誰會贏得AI時代？

目前的領先者：PostgreSQL

從三要素看，PostgreSQL在AI時代有先發優勢。Supabase和OpenAI的合作是標桿案例，pgvector證明它能同時處理結構化數據和向量搜索。云廠商的投資、開發者社區、工具生態都已形成。

但這不是定局。PostgreSQL的優勢來自2020s的云廠商生態，不是AI編程套件。誰能成為Claude Code、Cursor的默認數據庫，誰就有機會彎道超車。關鍵是2025-2026這兩年——AI編程工具的技術套件正在形成，第一個AI編程項目的大規模成功案例即將出現。誰能抓住這個窗口期，誰就是下一個DB市場贏家。

研究問題，而不是當粉絲

我的朋友馮若航寫了一篇。他提出的問題值得研究——為什么MySQL在中國互聯網行業占據統治地位？這是真實的現象，背后的機制確實需要解釋。

但把這個問題歸結為"服從測試"和"白酒文化"，是把技術選型的理性機制簡化成了文化批判。數據庫選型不是盲從，是技術套件綁定、標桿案例背書、生態系統網絡效應的綜合結果。選MySQL不是缺乏勇氣，選PostgreSQL也不是獨立思考的證明。都是在特定時代、特定技術套件下的理性選擇。

真正的問題是：技術選型如何運作？為什么某些技術在某個時代勝出？答案不在文化批判，在三要素。MySQL贏了2000s，PostgreSQL贏得2020s，都可以用三要素解釋。誰會贏得AI時代，也要看三要素。

工程師不應該是任何技術的粉絲。不要因為"PostgreSQL技術先進"就當PostgreSQL粉絲，也不要因為"MySQL是行業標準"就當MySQL粉絲。分析三要素，做出理性判斷，然后根據項目需求選擇。這才是工程師應有的態度。