LinkedIn 的「你可能認識的人」、Netflix 的「你也喜歡」、電商的詐欺偵測——這些功能的共同點是關係本身比資料更重要。
在關聯式資料庫裡建立「朋友關係」：user_relationships 表有 user_id_a 和 user_id_b。查「三度以內的朋友」需要 3 次 SELF JOIN，每增加一度查詢複雜度指數成長。100 萬用戶、每人平均 200 個朋友——三度人脈查詢在 PostgreSQL 上可能要幾分鐘。
Graph DB 的核心差異：關係有自己的 index，從一個節點走到相鄰節點的成本是 O(1)，不管總資料量多大。
核心概念
Node（節點）：代表實體。用 label 分類（:User、:Product、:Article）。
Relationship（關係）：連接兩個節點，有方向（→）和類型（FOLLOWS、PURCHASED、WROTE）。
Property：節點和關係都可以有屬性（name: "Alice"、since: 2023）。
-- Cypher 查詢：找 Alice 的二度朋友（朋友的朋友）
MATCH (alice:User {name: "Alice"})-[:FRIEND]->(friend)-[:FRIEND]->(fof)
WHERE NOT (alice)-[:FRIEND]->(fof) AND alice <> fof
RETURN fof.name, COUNT(*) AS common_friends
ORDER BY common_friends DESC在 Neo4j 上這個查詢對幾百萬節點仍然是毫秒級，因為它走的是真實的 graph traversal，不是 JOIN。
適合用 Graph DB 的場景
社交圖譜：用戶關係、粉絲、追蹤、社群發現。
推薦引擎：「看過 A 的人也看過 B」——協同過濾用 graph traversal 比矩陣分解更直觀。
詐欺偵測：同一個 IP 地址登入過多少帳號、這張信用卡跟已知詐欺帳號有幾度分離。
知識圖譜：Google Knowledge Graph、企業內的 entity relationship（員工-部門-專案-技能）。
Access Control / Permission Inheritance：「這個角色繼承那個角色的權限」——權限的傳遞性很自然地用圖來表達。
不適合用 Graph DB 的場景
- 高並發的簡單 CRUD（訂單、用戶 profile）——用 PostgreSQL
- 大量數值聚合（報表、分析）——用 OLAP
- 文件搜尋——用 Elasticsearch
- 已有的關聯式資料，關係不複雜——遷移成本 > 收益
主要產品
Neo4j：最成熟的圖資料庫，Cypher 查詢語言標準化程度高，有開源版和企業版。AuraDB 是其 cloud 託管版本。
Amazon Neptune：AWS 托管，同時支援 property graph（Gremlin）和 RDF（SPARQL）。適合已在 AWS 生態的團隊。
JanusGraph：分散式 graph DB，建在 Cassandra / HBase 上，適合 TB 級超大圖。
Dgraph：原生 GraphQL，分散式，Go 實作，開源。
ArangoDB：多模型（graph + document + key-value），適合需要混合查詢的場景。
Graph DB 不是 PostgreSQL 的替代
Graph DB 是補充，不是替代。大多數系統的大多數資料仍然適合放在關聯式資料庫裡。
當你的資料模型開始出現「多跳關係查詢」、「關係本身有屬性」、「path 找最短路徑」這類需求時，才是考慮引入 Graph DB 的時機。很多系統用 PostgreSQL + graph extension（如 pgRouting 或 Apache AGE）就能解決 80% 的圖查詢需求，不需要引入獨立的 graph DB。