在数据库选型时，一个常见的困惑是：当业务同时需要关系型数据、文档存储和图查询时，究竟是选PostgreSQL加上各种扩展，还是直接上一个原生多模型数据库？ArangoDB正是这类讨论中最常被提到的产品，它宣称用一套核心同时支持文档、图和搜索三种模型。而PostgreSQL这边，凭借JSONB、递归CTE以及Apache AGE等扩展，也宣称自己是一个“多模型”数据库。两条路线看似殊途同归，实际体验却差异不小，下面从几个关键维度展开对比。
存储模型与架构思路的根本差异
PostgreSQL诞生于上世纪八十年代，它的内核是围绕关系模型构建的。表、行、列是最基本的组织单位，即使后来加入JSONB类型，文档本质上仍然存储在表的某一列中，围绕它建立的GIN索引也只是B树体系之外的另一种索引结构。换句话说，PostgreSQL的多模型能力是“在关系模型之上叠加”出来的。
ArangoDB的思路则完全不同。它的存储层直接以文档集合为基础单位，JSON文档是原生数据形态，而图模型中的边实际也是一种特殊的文档，包含_from和_to两个必须指向文档ID的属性。这种设计让文档和图天然共用一套存储引擎和事务机制，不需要在任何一层做翻译和适配。搜索能力则通过内建的ArangoSearch视图实现，同样集成在同一内核中。
这种架构差异带来的直接影响是：在PostgreSQL里，如果你要在关系表、JSONB列和图扩展之间做联合查询，不同部分的能力边界比较明显；而在ArangoDB里，一条AQL语句可以自然地混合文档过滤、图遍历和全文检索，语法上是连贯的。当然，PostgreSQL在纯关系场景下的成熟度、优化器能力和生态工具链，又是ArangoDB短期内难以追赶的。
查询语言对比：SQL生态与AQL的表达力
PostgreSQL使用标准SQL，这是它最大的护城河之一。JSONB的操作通过一系列操作符完成，比如->提取JSON字段，@>做包含性判断，配合GIN索引可以获得不错的文档查询性能。
-- 在JSONB字段上做文档式查询
SELECT data->>'name' AS name, data->'address'->>'city' AS city
FROM customers
WHERE data @> '{"tags": ["vip"]}'
ORDER BY data->>'created_at' DESC
LIMIT 20;图查询方面，传统做法是使用递归CTE实现路径遍历，语法繁琐且性能一般。如果安装Apache AGE扩展，则可以使用openCypher风格的查询，体验接近Neo4j。但扩展毕竟不是内核原生，版本兼容和运维复杂度都需要额外考虑。
ArangoDB的AQL则是为多模型量身定制的语言，语法风格介于SQL和JavaScript之间，图遍历是一等公民。看一下典型的多跳查询：
// 查询某个用户的三度人脉中购买了指定商品的人
FOR v, e, p IN 1..3 OUTBOUND 'users/alice' knows, ANY purchases
FILTER p.edges[*].status ALL == 'active'
FILTER v.type == 'person'
RETURN DISTINCT { user: v.name, path: LENGTH(p.edges) }这条语句里，1..3定义了可变深度遍历，p.edges可以直接对整条路径做过滤，这在SQL体系中要写多层自连接或递归CTE才能实现。AQL还支持LET定义中间变量、子查询嵌套、以及把图遍历结果直接交给全文检索视图过滤，表达力确实更贴合多模型场景。代价是团队需要学习一门新语言，而SQL的普及度是AQL永远无法企及的。
图处理、事务与性能的实战表现
图处理是两者差距最明显的地方。ArangoDB原生支持顶点和边的批量操作、最短路径、广度优先遍历，针对图遍历做了专门的优化，在两三跳以内的社交关系、权限继承、风控关联分析等场景中性能表现稳定。PostgreSQL在数据量小、深度浅时用递归CTE也能应付，但一旦遍历深度增加或者边表达到千万级，查询耗时往往呈指数级恶化。
事务方面两者都是ACID compliant，但细节不同。PostgreSQL的MVCC实现经过几十年的打磨，支持串行化隔离级别、savepoint、两阶段提交等完整能力。ArangoDB的事务默认是集合级别的，如果一次事务涉及多个集合，可以声明stream transaction，但需要注意锁粒度对并发的影响。对于金融类强一致性业务，PostgreSQL的可靠性记录更有说服力。
性能上没有绝对赢家。纯OLTP的关系型读写，PostgreSQL明显占优；混合了文档写入加图查询的负载，ArangoDB的架构更省心，省去了多套系统之间的数据同步。另外ArangoDB支持集群模式下的分片和SmartGraphs优化分布式图遍历，而PostgreSQL的分布式方案要么靠Citus扩展，要么靠应用层分库分表，复杂度都不低。
如何根据业务场景做选择
一个简单有效的判断方法：先看核心数据形态。如果业务以结构化关系数据为主，文档和图只是边缘需求，比如偶尔存储一点配置JSON、偶尔查一下组织架构树，那么PostgreSQL一个库全搞定，运维简单、人才好找，JSONB加递归CTE已经够用，没必要引入新组件。
反过来，如果图关系本身就是业务核心，比如社交网络、知识图谱、反欺诈关联分析、推荐系统的物品关系图，同时又有大量文档型数据需要灵活schema，那么ArangoDB的原生多模型会减少很多别扭的胶水代码。尤其当团队发现自己在PostgreSQL里写了大量自连接、维护了一张越来越大的边表、还在考虑装AGE扩展时，就值得认真评估一次ArangoDB了。
还要考虑团队因素。SQL技能几乎每个后端工程师都有，AQL则需要培训成本；但ArangoDB的HTTP API和官方驱动对各语言支持完善，上手门槛其实比想象中低。最后一点务实的建议：两者并不互斥，不少团队的做法是用PostgreSQL承载交易主链路，用ArangoDB做关系分析和图计算，通过消息队列或CDC工具保持数据同步，各取所长往往是更稳妥的工程选择。
PostgreSQLArangoDB多模型数据库修改时间：2026-09-16 09:56:38