WordPress 只能用 MySQL？PostgreSQL 笑了！挑戰「預設值」的迷思
☰ 目錄 table-of-contents.md
WordPress 不是「只能」用 MySQL
翻開 wp-config.php，資料庫設定永遠預設指向 MySQL，但這個「常識」其實是 2003 年 LAMP 時代留下的歷史包袱，而不是技術鐵律。WordPress 核心確實是為 MySQL 量身打造，但透過相容性層（例如 PG4WP 專案），它一樣能跑在 PostgreSQL 上。真正值得花時間想清楚的，是你該不該這麼做。
直接回答你的問題：絕大多數的部落格、形象網站、中小型 WooCommerce 商店，請繼續用 MySQL，這是最平坦、社群支援最豐富的路。只有當你把 WordPress 當成「應用程式開發框架」、且對資料完整性或進階資料能力（JSONB、PostGIS、時序資料）有硬性需求時，PostgreSQL 才值得你承擔外掛相容性與維運成本去換取它的優勢。
在我們這個圈子裡，有些事情幾乎跟呼吸一樣自然，比如「WordPress 的網站就是用 MySQL」。這就像漢堡要配可樂一樣，是個不成文的規定。但身為工程師，我們的天職就是質疑「理所當然」。今天我就帶大家走一條比較少人走的路，認真聊聊 WordPress 的另一個資料庫選擇：PostgreSQL，也就是那隻被開發者暱稱為「Postgres」的藍色大象。
為什麼 WordPress 預設擁抱 MySQL？是歷史共業還是天作之合？
要理解 WordPress 和 MySQL 為何密不可分，得把時光倒流到 2003 年。那是一個網頁開發的蠻荒時代，當時最火紅的技術組合是所謂的「LAMP」：Linux（作業系統）、Apache（網頁伺服器）、MySQL（資料庫）和 PHP（程式語言）。WordPress 正是在這個生態系中誕生的。
所以 WordPress 選擇 MySQL，與其說是技術上的深思熟慮，不如說是時勢所趨。當時的關鍵因素有三個：
- 易用性與普及率：相較於當時的 PostgreSQL，MySQL 對新手更容易上手。幾乎所有的虛擬主機（Shared Hosting）都預設提供 MySQL，大幅降低了架站門檻。
- 社群與資源：因為用的人多，相關教學、文件、論壇討論鋪天蓋地。遇到問題隨便搜尋一下，就能找到一大堆 WordPress + MySQL 的解決方案。
- 效能迷思：早期 MySQL 的 MyISAM 儲存引擎在處理大量讀取時表現出色，對以內容發布為主的部落格系統來說堪稱絕配。不過得囉嗦一句：MyISAM 的高讀取效能是犧牲了交易與資料完整性換來的，對早期部落格而言這點犧牲值得，但對交易型應用就不適用。
於是 WordPress 與 MySQL 的結合，更像一場成功的商業聯姻，共同打造了龐大的生態系。但隨著網站需求越來越複雜，這對「黃金組合」也開始面臨新的挑戰。
MySQL 的極限在哪？當你的 WordPress 網站開始「長大」
一個簡單的部落格或企業形象網站，用 MySQL 絕對綽綽有餘。但當網站演化成擁有大量會員、商品 SKU 龐雜的 WooCommerce 商城，或是需要處理複雜數據分析的平台時，你可能會開始撞到 MySQL 的天花板。以下兩個面向最常見。
惱人的資料一致性問題
你遇過 WooCommerce 訂單超賣，或會員點數計算錯誤的狀況嗎？這很多時候跟資料庫的「交易（Transaction）」處理有關。
需要澄清的是：現代 MySQL 的主流引擎 InnoDB 同樣支援 ACID（不可分割性、一致性、隔離性、持久性），交易能力並不弱。兩者的差異更多在「設計理念」——PostgreSQL 對資料完整性與正確性的要求一向以嚴格著稱，型別檢查與約束（constraint）的把關更緊。在金融交易、庫存管理這類一分一毫都不能出錯的場景下，這份「龜毛」會讓開發者睡得更安穩。換句話說，這不是「MySQL 不能用」，而是「PostgreSQL 在嚴格性上預設更保守」。
複雜查詢的效能瓶頸
隨著業務邏輯變複雜，SQL 查詢語句也會越來越長、越來越難讀。當你需要用到多層子查詢（Subqueries）、通用資料表運算式（CTE，Common Table Expression）或視窗函式（Window Functions）來做數據分析報表時，PostgreSQL 的查詢優化器（Query Optimizer）在處理這類複雜查詢時通常更成熟，計畫選擇也更聰明。
一個好記的比喻：MySQL 擅長短跑衝刺（簡單、單純的讀寫查詢），而 PostgreSQL 更像一位馬拉松選手，擅長處理複雜且長途的耐力賽。當然，現代 MySQL 也已支援 CTE 與視窗函式，差別在於面對深層巢狀、多重聚合的分析查詢時，PostgreSQL 的優化器往往更不容易「想不開」。
PostgreSQL 的逆襲：哪些能力是 WordPress 專案的「秘密武器」？
如果說 MySQL 是大眾市場的國民車，那 PostgreSQL 就是專為特定賽道打造的高性能跑車。它不見得適合每個人，但在對的場景下能發揮驚人威力。以下是最值得關注的三項能力。
無可比擬的資料完整性與 ACID 合規性
這點前面提過，但值得再次強調。PostgreSQL 從骨子裡就是為「正確性」而生：嚴格的資料型別檢查、強大的約束機制與交易控制，能最大程度避免髒數據（Dirty Data）混進你的系統。對於那些「資料就是黃金」的企業來說，這份安心感是無價的。
強大的擴展性：它不只是個資料庫
PostgreSQL 最迷人的地方在於它的擴展性。透過各種擴充套件（Extensions），你可以讓它變身成不同的怪獸：
- PostGIS：讓資料庫具備地理空間（geospatial）處理能力。想像在 WordPress 後台做一個「尋找附近店家」的功能，或是地圖式的地點分析，PostGIS 能讓這類查詢變得直觀又有效率。
- TimescaleDB：把 PostgreSQL 轉變為高效能的時序資料庫（Time-series Database）。如果你需要在 WordPress 網站上收集並分析大量日誌（logs）、IoT 裝置數據或流量分析數據，這會是相當稱手的工具。
這些都是 MySQL 較難企及的領域，也是 PostgreSQL 在企業級應用中備受青睞的原因。
更豐富的資料類型與索引
身為工程師，看到 PostgreSQL 提供的資料類型時真的會心花怒放。除了標準型別，它還原生支援陣列（Array）、範圍（Range），以及最逆天的 JSONB。
JSONB 是一種二進位的 JSON 儲存格式，它不僅可以被索引（例如以 GIN 索引加速），還能對其內部欄位進行高效查詢。這代表什麼？老實說，每次看到 WordPress 核心用 wp_postmeta 這種 EAV（Entity-Attribute-Value，實體—屬性—值）設計來儲存各種中繼資料，我的眉頭都會皺一下。
為什麼 EAV 在資料量大時會痛？因為一筆內容的每個自訂欄位都被拆成獨立的一列（row），要同時依多個欄位篩選時，往往得對同一張表反覆 JOIN 自己一次又一次，查詢計畫越長越慢。而 JSONB 的思路是把同一筆內容的自訂欄位整包存在一個欄位裡，篩選時直接對這個結構化欄位下手：
-- 傳統 wp_postmeta 查詢，依兩個 meta 條件篩選需要多次 JOIN
SELECT p.ID, p.post_title
FROM wp_posts p
JOIN wp_postmeta pm1 ON (p.ID = pm1.post_id AND pm1.meta_key = 'product_price' AND pm1.meta_value > 1000)
JOIN wp_postmeta pm2 ON (p.ID = pm2.post_id AND pm2.meta_key = 'product_color' AND pm2.meta_value = 'blue');
-- 使用 PostgreSQL JSONB 的概念性查詢：同一個欄位內直接取值篩選
SELECT ID, post_title
FROM wp_posts_pg
WHERE post_meta ->> 'product_price' > '1000'
AND post_meta ->> 'product_color' = 'blue';
看看上面的範例，是不是優雅多了？要提醒的是：上面的價格比較只是示意，實務上以字串比較數字會出錯，正式使用時應將取出的值轉成數值型別（cast）再比較，並為常用查詢路徑建立適當索引。重點在於「結構思維」的差異，而不是把這段語法照抄上線。
殘酷的現實：在 WordPress 上用 PostgreSQL 有哪些挑戰？
講了這麼多 PostgreSQL 的好話，也該潑點冷水。在 WordPress 上使用 PostgreSQL 不是不可能，但絕對是一條充滿挑戰的荊棘之路。以下三道關卡，每一道都可能讓你停下來重新評估。
- 核心支援度：WordPress 核心程式碼是為 MySQL 量身打造的。你需要透過像 PG4WP（PostgreSQL for WordPress） 這樣的第三方相容性層來轉譯，但這也意味著你得承擔潛在的相容性風險，並隨核心改版持續驗證。
- 外掛相容性（最大的魔王）：市面上有成千上萬的 WordPress 外掛，其中不少寫死了 MySQL 專屬（MySQL-specific）的 SQL 語法。只要有一個關鍵外掛不相容，你的網站就可能隨時出狀況。這代表你得仔細審核每一個要安裝的外掛，甚至可能得自己動手修改外掛程式碼。
- 主機與社群支援：針對「WordPress + PostgreSQL」優化的主機方案相對稀少，遇到問題時能直接套用的現成解答也比 MySQL 少得多。這非常考驗開發團隊自行除錯的能力。
決策清單：我該為這個 WordPress 專案選 PostgreSQL 嗎？
繞了一大圈，答案是老話一句：It depends，取決於你的專案性質與團隊能力。把下面兩張清單對照自己的情況，答案通常就會浮現。
請繼續使用 MySQL，如果你符合以下任一項：
- 你的網站是標準的部落格、形象網站，或中小型 WooCommerce 商店。
- 你高度依賴各種第三方外掛來擴充功能。
- 你希望開發與維護路線最平坦、社群支援最豐富。
- 你的開發團隊對 MySQL 以外的資料庫不熟悉。
你可以勇敢挑戰 PostgreSQL，如果你符合以下情況：
- 你正把 WordPress 當成「應用程式開發框架」，而不只是一個 CMS。
- 你的專案有極高的資料完整性要求（如金融、科學數據）。
- 你需要 PostgreSQL 特有的進階能力（如 PostGIS 地理空間查詢、JSONB 結構化中繼資料）。
- 你擁有一支技術實力堅強的團隊，能處理相容性問題並撰寫高品質的客製化程式碼。
最後，Eric 想再囉嗦幾句：技術選型從來沒有標準答案。選資料庫不是在選「最強」的，而是在選「最適合」的。盲目追隨潮流或固守傳統都不可取。真正重要的是深入了解你的業務需求，評估不同工具的優劣與成本，然後做出一個負責任、經得起考驗的技術決策。這，才是工程師的價值所在。
延伸閱讀
常見問題
WordPress 只能使用 MySQL 嗎？
WordPress 網站該用 MySQL 還是 PostgreSQL？
在 WordPress 上使用 PostgreSQL 會遇到哪些挑戰？
PostgreSQL 相較 MySQL 在 WordPress 場景有什麼優勢？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。