PostgreSQL 19 移除 SQL/PGQ 之后pgGraph 路线图与 Postgres 图查询的未来2026 年 9 月 7 日PostgreSQL 官方团队将 SQL/PGQ 从 PostgreSQL 19 的发布分支中正式移除。对于想在 Postgres 里做图查询的开发者来说这个消息意味着什么开源项目 pgGraph 又将走向何方pgGraph 是一个 PostgreSQL 扩展能让现有的 Postgres 数据在不迁移的前提下获得图搜索、遍历和最短路径能力。本文用通俗的方式讲清这件事并梳理 pgGraph 的路线图。SQL/PGQ 是怎么被移出 PostgreSQL 19 的先花一分钟科普SQL/PGQSQL-Property Graph Queries是 PostgreSQL 生态里最早的原生图查询方案之一它提供CREATE PROPERTY GRAPH、GRAPH_TABLE、shortest_path()等标准语法让你直接用 SQL 描述图模式。它于 2022 年并入 PostgreSQL 主线此后一直跟随官方版本发布。但转折发生在 PostgreSQL 19 的发布准备期官方于 2026 年 9 月 7 日通过 revert 提交将 SQL/PGQ 整体移出 19 的发布分支PostgreSQL 19 正式包中不再包含它。相关说明见 README.md 与 docs/roadmap.mdx。这次移除传递出一个清晰信号SQL/PGQ 的语法体系与正在推进的 ISO GQL / SQL:2023 图查询标准方向不一致官方更倾向于把SQL 原生图查询的演进交给新标准而不是维护两套图查询引擎。 Postgres 图查询生态的三条路线SQL/PGQ 离场后想在 Postgres 生态里做图查询主要有三条路路线代表方案现状SQL 原生图查询语法SQL/PGQ已移出 PostgreSQL 19仅存于 18 及更早版本图加速扩展不动现有表pgGraph支持 PostgreSQL 14–18不依赖 SQL/PGQ属性图数据库Apache AGE基于 openCypher需要独立的图命名空间与顶/边表数据要迁入标准查询语言ISO GQL / SQL:2023标准化进行中主流数据库的原生支持仍在演进两条路线最容易被混淆这里用一个比喻区分Apache AGE是Postgres 里装了一座图数据库——数据要搬进图命名空间pgGraph是给你的关系表装了一个图加速层——表仍是唯一事实来源它只在上面构建可重建的图索引。pgGraph 的回应它从一开始就不依赖 SQL/PGQ对 pgGraph 来说这次移除更像解除了干扰项而非打击因为它从未把 SQL/PGQ 当作运行基础支持范围明确pgGraph 支持PostgreSQL 14–18这一契约记录在机器可读的 release/v1-contract.json 中supported_majors为 14 至 18。架构定位不同SQL/PGQ 是用 SQL 表达图模式、让优化器决定怎么执行pgGraph 则把关系数据编译成 CSR压缩稀疏行邻接存储专为反复、有深度上限的图遍历做预计算属于执行层加速。SQL/PGQ 适配器只是预留缝源码中存在一个内部类型化适配层 graph/src/query/sqlpgq_adapter.rs它刻意不解析 SQL/PGQ 文本也没有任何公开的 SQL/PGQ API。docs/known-issues.mdx 也明确写着GRAPH_TABLE不在 pgGraph 的 PostgreSQL 14–18 契约之内。版本退役有保护期根据 docs/user_guide/versioning-and-compatibility.mdx 的版本策略patch 版本永不淘汰某个 PG 大版本minor 版本也只在上游 PostgreSQL 停止支持、并提前至少一个 minor 版本和 90 天通知后才会退役某个大版本。也就是说即使 PostgreSQL 19 发布使用 14–18 的用户完全不受影响pgGraph 会继续作为 14–18 的支持线稳定演进。️ pgGraph 路线图SQL/PGQ 移除之后的六个方向官方路线图docs/roadmap.mdx把PostgreSQL 版本兼容性与未来原生 SQL/PGQ 集成明确拆成两条独立方向且原生集成没有承诺任何目标大版本。未来版本可能改进的六个大方向翻译成大白话就是更大规模下的可见性RLS性能细粒度行级安全策略的规模化验证与自适应执行完成一次权限判定后不推倒重来路径与遍历能力扩展更多的有界路径、遍历形态以及查询语言GQL / Cypher 子集与分析功能覆盖批量导入更顺手在权威 PostgreSQL 表之上提供更好的集合式数据摄取体验同步与恢复更稳改进同步、持久化、崩溃恢复和资源治理拓扑原语开放提供可复用的拓扑基础组件供可选的外部消费者使用版本与性能覆盖扩展 PostgreSQL 版本覆盖、打包发布、标准一致性测试和性能基准。路线图也强调任何能力只有当实现、测试、公开文档、限制说明和发布说明四方一致时才会发布——这意味着用户看到的每一份文档都是可信的能力清单而不是愿景广告。当前的1.2.1版本则聚焦稳定性、同步与数据库隔离升级需更新扩展并重建每个图详见 docs/release-notes.mdx。⚙️ 现在该怎么做 Postgres 图查询实操建议如果你的数据已经在 PostgreSQL 14–18 里且不想迁移pgGraph 是阻力最小的选择。查询入口就是graphschema 下的普通 SQL 函数例如-- 建图后用 SQL 函数做图查询 SELECT * FROM graph.search(property_key : name, property_value : alice); SELECT * FROM graph.shortest_path(from_node : 1, to_node : 42);不需要学习新数据库也不需要写递归 CTE。更多查询模式见 docs/user_guide/querying.mdx能力边界见 docs/user_guide/limitations-and-fit.mdx。决策清单✅ 数据在 PG 14–18、要做有界遍历 / 最短路径 / 关系搜索且不想搬数据 → 选 pgGraph可用 scripts/quickstart.sh 一键跑起完整演示教程见 docs/quickstart.mdx⚖️ 需要完整的属性图模型或 openCypher 语法 → 评估 Apache AGE⏳ 已计划升级到 PostgreSQL 19 → 注意 19 官方包没有 SQL/PGQpgGraph 对 19 的兼容性支持在路线图中单独跟踪暂无承诺版本升级前建议先确认项目进展。写在最后SQL/PGQ 的离场不是 Postgres 图查询的终点而是一次路线的重新洗牌官方把 SQL 原生图查询交给了正在演进的 ISO GQL / SQL:2023 标准而像 pgGraph 这样不搬数据、直接加速现有关系表的图扩展反而获得了更干净的定位。对于绝大多数想在现有 Postgres 体系内快速获得图查询能力的团队14–18 版本的 pgGraph 依然是当下最务实的选择——你的表不动SQL 不学新的图能力直接到位。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考