AgensGraph 2.18.6.1 已发布，它构建在 PostgreSQL 18.6 之上，新增了首批 ISO GQL（ISO/IEC 39075，面向属性图的国际标准查询语言）子句，并重写了变长遍历的索引使用方式。对已经在用 PostgreSQL、又想引入图查询能力的团队，这个版本值得放进测试环境评估；但它是否适合替换现有图数据库，取决于你的数据规模、升级窗口和查询模式，不能只看功能清单。

版本信息与事实边界

根据 PostgreSQL 官方新闻页 2026 年 11 月 7 日的公告，发布方为 SKAI Worldwide（原 Bitnine），2.18 系列当前版本号为 v2.18.6.1。AgensGraph 以 Apache License 2.0 发布，自 2016 年起持续开发，定位是多模型图数据库：在 PostgreSQL 基础上扩展 openCypher 与 ISO GQL 子句，使 SQL 与图查询可以运行在同一份数据、同一个事务，甚至同一条语句中。

需要说明的是，本文依据的是厂商发布公告，性能数字为官方自述，UU云未做独立复测。公告未披露测试硬件、并发条件和数据集细节，因此下文引用的性能对比只说明官方声称的改进方向，不能直接换算成你生产环境的预期。

变化一：ISO GQL 首批子句与 openCypher 并存

2.18 新增的 GQL 子句包括 LET、FOR、FILTER、NEXT、FINISH 和 INSERT，另有独立的 ORDER BY、OFFSET、LIMIT。公告称这是向 GQL 标准靠拢的第一步，后续版本会继续补齐。

对开发者的实际影响在于写法选择：已有 openCypher 查询可以继续使用，新写的查询可以逐步尝试 GQL 子句。但公告只说明是“首批”，没有给出已实现子句相对标准全文的覆盖比例。如果你的项目要求严格符合 GQL 标准，应先在测试库中验证目标语法是否被支持，而不是假设标准写法全部可用。

变化二：变长遍历改为逐跳使用边标签索引

这是本次性能改进的核心。2.17 在变长遍历的每一跳都会扫描整个标签，2.18 改为在每一跳使用边标签的索引。公告给出的例子是：在公开的 soc-Pokec 图（约 3000 万条边）上，一次两跳遍历在 2.17 的测试中 20 秒内未完成，2.18 可在毫秒级完成。

这个方向对多跳关系查询（社交关系、知识图谱、权限链路）意义明显，但要注意三点：一是数据来自厂商自述；二是 soc-Pokec 是公开数据集，与你的业务数据分布差异可能很大；三是索引能否生效与标签设计、统计信息、查询写法有关。建议用自己的数据做对照测试，观察执行计划中是否真的走了边标签索引。

变化三：类型化属性列、行级安全与 PostgreSQL 18.6 特性

高频查询的属性现在可以存为原生类型化列，并像普通 PostgreSQL 列一样建索引，用于加速过滤和排序。这相当于把图属性的一部分“下沉”到关系表结构里，适合属性模式稳定、过滤条件集中的场景；属性高度动态的场景则要权衡表结构变更的成本。

安全方面，Cypher 写入现在会执行行级安全策略；定长模式查询也会对其匹配到但未在语句中点名的标签执行行级安全与权限检查。对多租户或按标签隔离数据的部署，这是实质性变化，升级后应回归验证原有权限假设是否仍然成立。

继承自 PostgreSQL 18.6 的能力包括异步 I/O、uuidv7()、虚拟生成列、OAuth 认证、B-tree skip scan，以及截至 18.6 的修复。这些属于 PostgreSQL 层面的改进，具体可用性以 PostgreSQL 18.6 文档为准。

AI 与 Python 生态：驱动重写与 GraphRAG 集成

agensgraph-python 2.1 基于 psycopg 3 重写，支持同步与异步代码，可在同一事务中运行 Cypher 与 SQL，并把顶点、边、路径返回为原生 Python 对象。查询结果可直接载入 pandas、Polars 或 Arrow 做分析，同时提供连接池、批量加载和 OpenTelemetry 追踪。

agensgraph-ai 提供 LangChain（含 LangGraph checkpointer 与 store）、LlamaIndex、LightRAG、cognee 的集成，以及让 AI 助手操作图数据的 MCP 服务器。配合单独安装的 pgvector 扩展，图数据与向量嵌入可以放在同一个数据库中，单条查询即可组合图遍历与向量相似度检索。

这些集成的具体版本兼容矩阵公告未列明，pgvector 与 AgensGraph 2.18 的推荐版本组合也未说明。搭建原型前，应以各项目官方文档核对依赖版本，避免在集成层反复排查版本问题。

升级路径：2.17 数据目录不能直接使用

公告明确说明，2.17 的数据目录不能直接用于 2.18，需要走升级流程。已在 2.18.6.0 的安装只需替换二进制并重启。以下步骤适用于自建实例，操作前请确认已具备数据库超级用户权限和可用的备份空间。

1. 完整备份现有 2.17 实例，并验证备份可恢复。升级失败时这是唯一的回滚依据。
2. 阅读官方发布说明中 2.17 到 2.18 的变更清单，确认是否有影响你现有查询或权限配置的改动。
3. 在测试实例上演练升级，二选一：使用 pg_upgrade 原地升级，或用 2.18 版本的 pg_dump 导出后在新实例恢复。
4. 升级完成后启动服务，检查日志中是否有扩展加载或权限相关报错。
5. 抽样执行核心图查询与 SQL 混合查询，对比结果正确性和执行计划，确认行级安全策略按预期生效。

# 示意：用 2.18 版本的 pg_dump 导出旧库，再恢复到新实例
# 具体路径与连接参数按你的环境替换
pg_dump -h 127.0.0.1 -p 5432 -U your_user -Fc your_db > your_db.dump
pg_restore -h 127.0.0.1 -p 5433 -U your_user -d your_db your_db.dump

这里 -Fc 表示自定义格式归档，便于 pg_restore 选择性恢复；-h、-p、-U、-d 分别指定主机、端口、用户和数据库。命令中的名称均为占位符，请按实际环境替换。

操作提醒

• 升级涉及停机窗口，生产库应提前评估业务可接受的中断时长，并准备回滚方案。
• 行级安全行为变化可能影响既有写入路径，升级后应在测试环境跑一遍权限相关用例。
• 不要在未备份的实例上直接尝试升级，也不要跳过测试环境演练。

对自建数据库团队的实际意义

AgensGraph 2.18 的价值主要集中在“减少组件数量”：图查询与 SQL 同库同事务，意味着不必为图分析单独维护一套数据库，对已有 PostgreSQL 运维经验的团队，学习与运维成本相对可控。适合评估的场景包括关系型数据中已有大量关联查询、需要多跳遍历的知识图谱或权限链路、以及希望把图检索与向量检索放在一起的 GraphRAG 原型。

需要谨慎的场景同样明确：图数据规模很大且查询以超多跳遍历为主时，专用图数据库的优化空间可能仍更充分；对升级停机极度敏感的核心库，应先评估 pg_upgrade 的实际耗时；对严格依赖 GQL 标准完整覆盖的项目，当前只是“首批子句”，不宜过早绑定。

部署层面，图遍历与向量检索对内存和磁盘 IO 较敏感，配置应以自己的数据量和并发压测结果为准，而不是照搬公告中的测试规模。如果实例部署在海外机房，建议先测目标用户所在地区的线路延迟，再决定机房位置；规格与计费方式以对应服务商的官方产品页为准。

常见问题

AgensGraph 2.18 能直接替换现有的 Neo4j 部署吗？

不能简单等同。两者查询语言生态、驱动和运维方式不同，AgensGraph 的优势在于与 PostgreSQL 同库同事务。是否替换要看现有 Cypher 查询的兼容程度、迁移成本和团队对 PostgreSQL 的熟悉度，建议先用真实查询做小范围验证。

公告里“20 秒缩短到毫秒级”能套用到我的业务数据吗？

不能。该数字来自厂商在 soc-Pokec 公开数据集上的测试，硬件与并发条件未披露。你的数据分布、标签设计和查询写法都会影响结果，应以自己的数据做基准测试。

升级必须停机吗？

公告给出的两条路径——pg_upgrade 或 pg_dump 导出后恢复——通常都需要一定的写入停止窗口。具体时长取决于数据量和硬件，建议在测试环境先跑一遍测量。

pgvector 需要额外安装吗？

需要。公告说明 pgvector 为单独安装的扩展，安装后才能在同一数据库中组合图遍历与向量相似度检索。版本组合请以官方文档核对。

已经在 2.18.6.0 上，还需要做数据迁移吗？

不需要。公告说明已在该版本的安装只需替换二进制并重启即可。