常見的架構演進路徑是：原本的關聯式數據庫繼續存放實體數據與核心欄位；新增圖數據庫專門存放實體間的關係，主攻多跳查詢（Multi-hop Traversal）；然後由應用層（Application Layer）負責把兩邊的結果「黏」回同一個回傳物件。設計文件上看起來邊界清楚：關聯式回答「數據是什麼」、圖數據庫回答「數據怎麼連」，但真實世界的查詢需求幾乎不會乖乖待在單一模型裡。

實務上，多數查詢都是「屬性 ＋ 關係」的混合型態：先撈取「近 30 天活躍用戶」（屬性過濾，偏向關聯式），再看這批人之間的好友／互動關係（多跳遍歷，偏向圖數據庫）；或先找出「高風險帳戶」（屬性與交易紀錄過濾），再沿著關聯路徑往外擴散排查潛在關係人。這些在業務語意上其實是一個閉環，但在「關聯式 ＋ 圖數據庫」混用的架構下，會被迫拆成多段流程：先在關聯式數據庫過濾出 ID 清單、再同步或即時推送到圖數據庫、在圖裡面做遍歷、最後回到應用層進行二次拼裝與加工。真正吞噬企業開發成本的，往往是「跨系統拼接查詢語意」，而不是某一個數據庫本身。

接著，技術團隊會遇到更棘手的數據一致性（Data Consistency）問題：

• 實體在關聯式數據庫被刪除了，圖數據庫裡的邊（Edge）沒清乾淨，查詢就會冒出「幽靈關係」；
• 關聯式裡的關鍵屬性更新了（例如用戶狀態、帳戶等級），但圖的分析仍然吃到舊數據，導致結果失真；
• 同一個業務動作要同時修改兩邊數據時，兩次寫入很難做到原子性（Atomicity），常出現「一邊成功、一邊失敗」的窘境。

為了補救這些架構漏洞，團隊通常會加上事件驅動架構（Event-driven Architecture）／訊息隊列（Message Queue）、補償機制、定期檢核與修復任務，並在業務層接受某種程度的最終一致性（Eventual Consistency）；但這些「補強」措施會逐步把系統重心從創造業務價值，轉移到容錯與糾錯之上。

更容易被忽略、但殺傷力極強的是交易／事務（Transaction）語意被拆碎：原本在單一數據庫中，一個業務操作可以包在同一個 ACID 交易裡，失敗就完整回滾（Rollback）；混用之後，一次業務操作變成多次跨系統寫入，強一致性（Strong Consistency）常退化成最終一致性，回滾邏輯也被迫上移到應用層手動編寫。結果就是：狀態判斷充斥在核心流程中、錯誤處理「入侵」業務程式碼、系統行為變得越來越難以推理。排查一個問題需要跨兩套數據庫與整條呼叫鏈，定位成本大幅飆升。

當複雜度累積到某個臨界點，架構反而會限制業務的演進速度：一個微小的需求可能同時需要修改關聯式數據庫、圖數據庫、同步管道（Pipelines）與應用層拼裝；一個小異常可能要跨多個技術棧（數據庫、隊列、服務）追查數天。團隊的技術決策變得越來越保守，因為任何改動都可能踩爆既有的跨系統耦合點。這時，企業即便擁有了很強的圖查詢能力，也常常被「整合與一致性成本」徹底吞沒。

所以問題不在「圖數據庫」本身，而在於「分裂的數據視圖（Split Data Views）」：同一個業務視圖被硬生生拆成兩套（實體／屬性在關聯式，關係在圖數據庫），應用層被迫承擔「整合數據語意」的責任，而這本來應該盡量由數據層去吸收。業界也常把「同一個應用同時使用多種數據庫」的策略稱為多語言持久化（Polyglot Persistence），其優點是各取所長，但代價是整合與一致性難度更高、維運與營運複雜度大幅提升。

回到多模型數據庫（Multi-model Database）的解決思路：核心重點是「統一」，而不是在同一條核心鏈路上不斷地「疊加」技術棧。它想回答的是：

1. 能不能在同一個系統內同時表達實體、屬性與關係？
2. 能不能用一次查詢同時做到屬性過濾與關係遍歷？
3. 能不能在一致的交易語意（Transaction Semantics）下更新實體與關係，避免交易邊界被拆散？