RDBMS、DocumentDB、Knowledge Graph 三種資料庫怎麼選：老闆與 PM 看得懂的 schema、關係、查詢三維決策框架

RDBMS（PostgreSQL、MySQL）管交易與結構化分析、DocumentDB（MongoDB）管彈性 schema 與半結構化資料、Knowledge Graph（Neo4j）管多跳關係與語意推理——三者不互斥，2026 多數 AI 系統其實是三種一起用。判斷一筆資料該放哪個，看三個維度就夠：schema 嚴格度、關係深度、查詢型態。

這篇文章是寫給做技術決策的老闆、PM 和系統主管看的——你不需要懂寫 Cypher 或 PL/pgSQL，但你需要知道一筆訂單、一份對話 log、一張關係圖各自該躺在哪裡，才不會被工程團隊半年後回頭跟你說「這個架構要打掉重練」。

為什麼 2026 特別重要？因為 AI Agent 與 GraphRAG 把過去「選一個資料庫從一而終」的習慣徹底打碎。Neo4j 與 Microsoft Research 的對比實驗顯示：純向量 RAG 在 zero-shot 場景準確度約 20%、fine-tune 後拉到 80%；改用 GraphRAG（向量 + 知識圖譜）zero-shot 直接跳到 60-65%、fine-tune 後逼近 95%。同一份企業文件，「擺進對的資料結構」就是答對與答錯的差別。

市場走向也呼應了這件事。Allied Market Research 的估算，全球圖資料庫市場從 2019 年的 8 億美元，預計 2026 年突破 30–40 億美元，年複合成長率約 25%。Stack Overflow Developer Survey則顯示 PostgreSQL 從 2023 起連續三年穩坐開發者最喜愛資料庫第一名，文件型陣營 MongoDB 也在 Snowflake、Databricks 之間持續擴大市占。三條線一起往上跑——這就是為什麼今年你會發現工程師同事一邊寫 SQL、一邊在另一個 repo 用 MongoDB、又在第三個 repo 跑 Cypher。

三種資料庫差在哪？一張表分清 schema、關係、查詢

先把名字搞清楚，避免後面討論越討論越糊。RDBMS 是「關聯式資料庫管理系統」的縮寫，最有名的是 PostgreSQL、MySQL、SQL Server、Oracle——它用「表格 + 主鍵 + 外鍵」儲存資料，schema 寫死就不太能改。

DocumentDB 是「文件型資料庫」，把每一筆資料當成一份 JSON 文件存——MongoDB 是這個陣營的代表，AWS DocumentDB、Couchbase、Firestore 也屬於這類。它不要求每筆資料長一樣，可以一筆有「客戶等級」欄位、另一筆沒有，schema 用走就改。

Knowledge Graph 用「節點 + 關係」表達資料——一個客戶是節點、他「買了」一個商品是關係，這個商品的「製造商」又是另一個節點，關係彼此可以無限串接。Neo4j 是台灣業界最常見的圖資料庫，全球還有 Amazon Neptune、TigerGraph、ArangoDB、Memgraph 等選擇。

RDBMS 擅長什麼：交易、結構、SQL 分析的鐵打場景

RDBMS 是這三種裡面歷史最久的，也是最不容易選錯的——當你「不確定要選什麼」的時候，預設選 PostgreSQL，至少不會死。它是企業裡最能撐住營運核心的資料庫，原因有三個：交易保證、SQL 通用、生態圈成熟。

ACID 交易：營運最後一道防線

ACID 是 Atomicity、Consistency、Isolation、Durability 的縮寫——簡單講，「一筆轉帳要嘛全部成功要嘛全部失敗，絕對不會卡在中間」就是 ACID 想保證的事。任何牽涉到金錢、庫存、權限的場景，預設都應該躺在 RDBMS 裡。

舉個例子，在我們做過的製造業生產力管理系統（portfolio 真實案例）裡，「員工打卡、扣產線時數、結算當月薪資」這三個動作必須是一個交易——如果只扣到時數但沒結算薪資，會計部第二天就會炸鍋。PostgreSQL 一行 `BEGIN ... COMMIT` 就守住了；如果這套系統一開始選了 MongoDB，工程師要自己寫補償邏輯處理失敗回滾，等於把資料庫的事擋下來自己做。

SQL 是最容易找人接手的語言

這點老闆比工程師更在意。Stack Overflow Developer Survey 顯示 PostgreSQL 與 SQL 是開發者最熟悉的組合之一——當你三年後要換工程師，會 SQL 的人是會 Cypher 的 10 倍以上。Cypher 與 MongoDB Query 在台灣徵才市場依舊算「加分項目」，不是「人人會」。對中小企業老闆，這個「換手難度」直接決定了系統的長期維運成本。

PostgreSQL 在 AI 時代沒有退場，反而擴大

很多人以為 AI 時代 RDBMS 會被打趴——事實正好相反。pgvector 擴充套件讓 PostgreSQL 直接變成向量資料庫，這也是為什麼我們在向量資料庫選型完整指南裡會把它列為最推薦的「小規模 RAG 入門選擇」——不用另起一套基礎設施，原本的 RDBMS 就能順便當向量庫。

DocumentDB 擅長什麼：彈性 schema 與半結構化資料的解放

DocumentDB（MongoDB 為主）解決的核心問題是「我事先不知道資料會長什麼樣子」。這在 2026 變得特別常見——AI Agent 的對話 log、API 回傳的爬蟲結果、用戶上傳的表單、CRM 裡客戶自定義欄位，這些資料結構幾乎不可能一次定到位。

彈性 schema：把 migration 噩夢消滅

在 RDBMS 上改 schema 是會出事的操作——加一個欄位要鎖表、改型別要備份、刪欄位要寫遷移腳本，超過千萬筆資料時甚至要排在凌晨維護視窗。MongoDB 的設計理念是「同一個 collection 裡的文件不用長一樣」，今天加一個 `aiSegment` 欄位、明天加一個 `last_chatgpt_call_at`，前端寫進去就完事。

AI Agent 對話 log 的天然容器

你正在做 AI 客服系統嗎？AI Agent 的對話 log 是典型的半結構化資料——每段對話可能有 messages、tool_calls、retrieved_chunks、cost_usd、latency_ms，但每次 agent 用到的工具不一樣、retrieve 出的 chunks 數量不一樣、有沒有觸發人類 escalation 也不一樣。硬塞進 RDBMS 你會發現要嘛開一堆 NULL 欄位、要嘛改用 JSON column（其實就是繞回 DocumentDB）。

在我們客製化的電商 AI 智慧客服系統裡（portfolio #31），底層就是 PostgreSQL（管會員、訂單）+ MongoDB（管對話 log 與 agent state）的混搭——一個專案放兩種資料庫，2026 已經是常態，不再是 over-engineering。

Aggregation Pipeline：原生跑半結構化分析

MongoDB 的Aggregation Pipeline是一個串接的資料處理管道，可以一段段過濾、轉換、分組、計算。當你的資料是 JSON 巢狀結構（陣列、物件、各種型別混搭），用 Aggregation Pipeline 寫起來比 SQL 自然很多。實務上，「過去 30 天每個 AI 客服對話的平均處理時長、按客戶分群」這種查詢，在 MongoDB 是十幾行 pipeline，在 PostgreSQL 你得寫 CTE + JSON function + window function 一大段。

Knowledge Graph 擅長什麼：多跳關係與 GraphRAG 的 AI 殺手鐧

前面兩種都還是「資料是主角，關係是配角」。Knowledge Graph 把這件事翻轉過來——它認為「關係本身就是資料」，而且關係彼此可以串成網。

舉一個直覺的例子：你想知道「跟王老闆有三層內的合作關係、且在過去六個月有金流往來的供應商」，在 RDBMS 你要 JOIN 三次、性能直接崩盤；在 MongoDB 你要 lookup 三層、開發團隊會崩潰；在 Neo4j 一條 Cypher 查詢搞定，毫秒回應。這就是「多跳查詢」（multi-hop query）的本質差異。

2026 為什麼大家突然在談 Knowledge Graph

因為 GraphRAG。Microsoft Research 在 2024 提出 GraphRAG 後，2025 又推出 LazyGraphRAG，把建索引的成本壓到原本的 0.1%、Global Query 成本降到原來的 1/700，這把 GraphRAG 從「研究計畫」變成「中小企業可以負擔的選項」。

台灣本地的應用也快速展開。經濟部工業局的科技新知專欄和中華電信研究院近期都有 GraphRAG 的技術專文；國際大廠像 SAP 已在開發平台支援 GraphRAG，讓客戶能在 ERP 上面長出 AI Agent 客服與 ESG 內容稽核 Agent。這意味著「圖譜」已經不是 IT 部門的好奇心專案，是商務系統的標配能力。

Knowledge Graph 在企業裡的四個經典場景

• 推薦系統：「跟你買同樣商品的人，還買了什麼」這種協同過濾，在圖資料庫上是天然查詢；在 RDBMS 上要寫成多層 JOIN，動輒幾秒。
• 反詐欺與洗錢偵測：金融業看「A 帳戶轉給 B、B 轉給 C、C 在三天內把錢匯出境外」這種 ring，圖資料庫一條查詢就抓出來。RDBMS 上的同樣查詢要跑分鐘。
• 企業知識庫與 GraphRAG：把員工手冊、產品規格、合約條款抽成「實體 + 關係」圖譜，丟給 LLM 推理，就是 GraphRAG 的核心——答案比純向量 RAG 更不容易幻覺。
• 供應鏈追溯與資產關係：哪個零件來自哪個供應商、哪個製程影響哪個品質指標、哪個客戶的訂單卡在哪個庫位——這類關係追溯天生就是圖結構。

我們在做客製化系統諮詢時，常被問到「我已經有 PostgreSQL 了，要不要再多一套 Neo4j」。回答是：如果系統的「查詢痛點」是關係追蹤超過 3 層、或要做 GraphRAG，那加一套圖資料庫的投資回報率很高；如果只是普通的會員系統、訂單系統、CMS，硬塞 Neo4j 反而增加運維負擔。要再細看圖資料庫的選型細節，可以參考我們的「圖資料庫 Neo4j 完整介紹」。

延伸閱讀：圖資料庫 Neo4j 完整介紹：何時該從 PostgreSQL 升級。

三維決策框架：schema 嚴格度 × 關係深度 × 查詢型態

看了三種資料庫各擅勝場，下一個問題是：實際拿到一個需求，怎麼判斷該選哪一個？這裡給一個我們做客製化系統諮詢時實際使用的三維決策框架，老闆和 PM 都能套。

維度一：Schema 嚴格度

問自己：這份資料一年內欄位會改幾次？如果答案是「很少、改一次就跑 migration 沒關係」，選 RDBMS；如果答案是「常改、業務一直加新需求、欄位數量會爆炸」，選 DocumentDB。Knowledge Graph 在這個維度比較中性——它的 schema 是長在「節點 label + 關係 label」上，新增資料維度通常不需要 migration。

維度二：關係深度

問自己：最常見的查詢需要跨幾張表（或集合）？1–2 層用 RDBMS 或 DocumentDB 都好；3 層以上、或經常要做「跟誰有關、再跟誰有關」的遞迴查詢，Knowledge Graph 是唯一不會炸的選擇。

維度三：查詢型態

問自己：你的主要查詢是「精準過濾 + 聚合」（這個月毛利、這群客戶的總消費）？還是「結構彈性 + 全文搜尋」（找出所有提到某關鍵字的對話 log）？還是「關係遞迴 + 推理」（誰會買這個商品、誰跟誰有合作關係）？分別對應 RDBMS、DocumentDB、Knowledge Graph。

如果你還在猶豫先選哪一條，我們的 AI 顧問服務會在第一階段幫你把資料盤點清楚，避免半年後回頭重做。

AI 系統怎麼三種混搭：Hybrid 是 2026 主流

現實是這樣的：你做一個夠複雜的 AI Agent 系統，幾乎不可能只用一種資料庫。三種各司其職的混搭架構，才是 2026 的正解。

一個典型的企業 AI Agent 架構長什麼樣

我們在客製化系統諮詢中常規劃的混搭架構長這樣：

• PostgreSQL（RDBMS）：管會員、訂單、權限、計費——這些要 ACID 的東西放這。同時用 pgvector 擴充套件當小規模向量庫，省一套基礎設施。
• MongoDB（DocumentDB）：管 AI Agent 對話 log、agent state、外部 API 爬下來的半結構化資料、用戶上傳的非結構化表單。
• Neo4j（Knowledge Graph）：管 GraphRAG 的知識圖譜、產品/客戶/合作夥伴的關係網、推薦引擎的後端。
• Redis（快取）：擋在最前面當 session cache、rate limit、頻繁查詢的結果快取——這不算資料庫主角，但少了它整個系統會慢一階。

Hybrid RAG：為什麼純向量檢索不夠了

純向量 RAG 在 2023–2024 火過一輪，但跑進 production 後大家發現它有幾個結構性問題：對「全域問題」（如「公司過去一年發生過幾次資安事件」）回答品質差、對「需要多跳推理」的查詢容易斷鏈、檢索結果與真實事實的對應關係很難稽核。

這就是為什麼 Hybrid RAG（向量檢索 + 圖譜遍歷）變成 2026 的標準解。實測上，Neo4j 與 LlamaIndex 的對比顯示，同樣的企業文件集，純向量 RAG 在 zero-shot 約 20%、GraphRAG 可以做到 60-65%；經過 fine-tuning，前者拉到 80%、後者逼近 95%。對企業內部知識庫場景，這 10-15 個百分點的差距就是「員工會不會繼續用這套系統」的分水嶺。

延伸閱讀：企業內部知識庫建置完整指南：從 RAG 選型、權限治理到員工日常工作流的 90 天落地路線圖、Production RAG 系統實戰：從 PoC 到上線的 8 個關鍵技術選型決策。

報價區間與隱藏成本：地端、雲端 managed、運維人力

選資料庫只看「授權費」是會踩坑的。真正的成本由四部分組成：基礎設施、人力、學習成本、長期擴充成本。下表是 2026 上半年三類資料庫的 managed 雲端方案報價綜整（中小企業中小型部署）。

數據來自Neo4j 官方定價頁、MongoDB Atlas 定價與AWS RDS PostgreSQL 定價整理。實際報價會因地區、儲存類型、備份策略、跨區複本而浮動。

被低估的三個隱藏成本

• 運維人力：圖資料庫要有人會 Cypher、會看 query plan、會調 page cache。光人力一年 NT$150–300 萬。
• 資料同步成本：混搭架構需要 CDC（change data capture）或事件匯流排，把同一筆資料變更同步到不同資料庫。這個基礎建設常被低估。
• 資料遷移成本：選錯類型、半年後要換，遷移腳本、雙寫、停機視窗都要算進去。我們做過的客戶遷移案，平均遷移成本是當初買錯資料庫授權費的 5–10 倍。

選錯的代價：三個典型踩雷情境

下面三個是我們在系統客製化諮詢中反覆遇到的典型誤判，提供出來給你避坑。

情境一：把交易資料丟進 MongoDB，半年後遇到對帳災難

某電商團隊覺得「JSON 比較彈性」就把訂單、金流、庫存一起塞進 MongoDB，初期開發很快，但跑到月結時發現「同一筆訂單在不同文件裡狀態不一致」、「金流補單時鎖不住」、「庫存超賣」全部出來。錯不在 MongoDB——錯在這類「強一致性」需求應該躺在 RDBMS。後來的解法是把核心交易遷回 PostgreSQL、MongoDB 留給商品資料與評論等彈性結構，整套架構才穩住。

情境二：用 RDBMS 硬搞推薦系統，查詢三秒起跳

某內容平台想做「跟你看過同一系列的人還看了什麼」推薦，工程師用 PostgreSQL 寫了 3 層 JOIN + 子查詢，初期百萬筆資料還能跑、用戶量翻倍後查詢動輒 3 秒。把這部分搬到 Neo4j 後，同樣的查詢回到 30ms 內。

這個案子的教訓不是「PostgreSQL 不行」——是「關係查詢超過 3 層就該考慮 Knowledge Graph」。RDBMS 的 JOIN 性能會隨關聯數量呈指數惡化，圖資料庫的關係查詢是 O(1) 等級。

情境三：用 Knowledge Graph 做會員系統，運維成本壓垮新創

某 SaaS 新創團隊看了 GraphRAG 的論文，覺得未來都是圖譜的世界，連會員系統都用 Neo4j 起家。前三個月開發很快，但碰到三件事：第一，會 Cypher 的工程師難找、薪資高；第二，會計師要跑會員財報，沒有 SQL 接口；第三，Auth0 等身分驗證工具都預設對接 PostgreSQL/MySQL。最後不得不把會員系統遷回 PostgreSQL，Neo4j 留給推薦引擎。

常見問題與下一步

下面整理我們在客戶諮詢中最常被問到的六個問題。

這篇是我們資料庫主題系列的延伸，建議搭配閱讀：SQL vs NoSQL 差在哪？老闆該怎麼選資料庫、圖資料庫 Neo4j 完整介紹、向量資料庫選型完整指南，三篇一起看會建立完整的資料庫架構決策思考框架。