PG 杀入图数据库赛道，SQL/PGQ 进主干代码
digoal约 10 分钟本期播客
重磅消息: SQL/PGQ 进入 PG 主干代码, 图 SQL 回归关系数据库主航道
PostgreSQL 正式杀入图数据库腹地：SQL/PGQ 提交入主干，忘掉图插件吧，PG直接掀桌子了。
2026 年 3 月 16 日，PostgreSQL 提交了一个足以写进里程碑的 patch：
2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c
标题是：SQL Property Graph Queries (SQL/PGQ)
这不是“小功能”。
这是 PostgreSQL 对 SQL:2023 第 16 部分 ISO/IEC 9075-16:2023 的一次正面接招。commit 直接引入了：
GRAPH_TABLE图模式匹配表函数CREATE/ALTER/DROP PROPERTY GRAPH新系统目录和 information schema 视图 psql \dGpg_get_propgraphdef()
更关键的是 commit message 明确写了一句最值钱的话：
property graph 在 PostgreSQL 里是一种新的 relkind，但它“在很多方面像 view”，并且会在 rewriter 阶段改写成标准 relational query。
这句话，决定了这件事的技术意义，也决定了这篇文章的核心观点：
PostgreSQL 这次不是要变成“另一个图数据库”，而是要把图查询重新收编进 SQL 体系。
一旦这条路走通，受冲击最大的，未必是图数据库本身，而是企业里那些“为了图而图、为了产品边界而拆库”的架构习惯。
一、先说结论：这不是 PostgreSQL 去“做图库”，而是在重写图查询的游戏规则
很多人第一反应会是：
“PostgreSQL 也支持图了？那是不是要和原生图数据库正面打？”
这问题问偏了。
从 commit 自己的设计就能看出来，PostgreSQL 这次的路线不是：
先发明一套全新图存储引擎 再围绕图引擎设计独立执行器 再把关系世界和图世界硬拼到一起
它选的是另一条路线：
用 SQL 标准定义图语义，用 property graph 做逻辑抽象，再把查询重写回关系代数。
说白了就是：
PostgreSQL 不想让“图”成为一个需要另起炉灶的数据孤岛，而想让它成为关系数据库的一种高级查询视角。
这和很多图库产品的思路完全不同。
它不是在喊“我也有图能力了”，
而是在说：
图查询，不一定要靠一个独立数据库品类来完成。
这比“多一个功能”要凶得多。
PostgreSQL 2026 年度大戏来了, 扫海报中的二维码报名, 选择早鸟或通票(都含午餐和周边礼品), 可私信我要优惠码, 数量有限先到先得!
二、为什么这件事对 DBA、架构师、开发者都重要？
因为它同时改变了三类人的判断边界。
对 DBA 来说
过去你说“业务想做图分析”，常见动作是什么？
新上一套图库 新运维一套集群 新监控一套指标 新备份一套流程 新权限模型一套口径 新同步链路一套复杂度
也就是说，一个查询需求，换来一套系统级负担。
而 SQL/PGQ 的方向恰恰相反：
它把图能力尽量留在 PostgreSQL 现有的事务、权限、备份、恢复、监控、工具链里。
这意味着 DBA 最该关注的，不是“语法会不会写”，而是：
如果图查询可以在 PostgreSQL 内部完成，那企业是否还需要为中等复杂度图场景付出第二套数据库的全部运维成本？
对架构师来说
真正的架构问题，从来不是“图数据库酷不酷”，而是：
这个需求值不值得我为它引入一个新系统边界。
如果 PostgreSQL 现在开始提供标准化的图查询入口，那么很多原本依赖“专用图引擎”的场景，就要重新做 TCO 计算：
数据是否本来就主要在关系表里？ 图模型是否只是其中一种分析视角？ 是否必须追求极致多跳遍历性能？ 业务是否能接受重写成关系查询的执行特性？ 单系统的一致性、治理、合规价值，是否高于专用引擎的局部最优？
这才是架构师真正该问的问题。
对开发者来说
更现实一点：
过去很多团队做“社交关系”“推荐链路”“风控关联”“主数据血缘”，最后最痛苦的不是图算法，
而是数据怎么从事务库搬到图库、两边语义怎么对齐、权限怎么统一、调试怎么闭环。
如果 SQL/PGQ 真正进入 PostgreSQL 主干，那开发者会得到一个非常诱人的选项：
在熟悉的 SQL 世界里，直接写图模式匹配，而不是把数据搬去另一个方言宇宙。
三、这次提交到底加了什么？别只盯 GRAPH_TABLE
很多文章写这种 commit，容易只抓一个新语法。
但这次 patch 真正说明“不是玩票”的，恰恰是它加的不只是一条语句，而是一整套对象体系。
从 commit message 看，这次加的是：
GRAPH_TABLE：图模式匹配的表函数CREATE/ALTER/DROP PROPERTY GRAPH：图定义 DDL新系统目录和 information schema 视图 psql \dGpg_get_propgraphdef()：供pg_dump和psql使用
这意味着 PostgreSQL 不是只加了一个 parser 层玩具，
而是认真把 property graph 当成了可定义、可 introspect、可 dump、可管理的数据库对象。
这点很关键。
因为数据库功能能不能进生产，很多时候不是看“能不能跑”，而是看：
能不能看见 能不能管 能不能导出 能不能迁移 能不能放进权限和元数据治理体系
这次 patch 把这些配套一起带上，说明它的目标不是 demo，而是主干能力。
四、它的真正野心：让图成为“逻辑层能力”，而不是“物理层分叉”
这里是最值得掰开的地方。
commit message 明确说：
property graph 是新的 relkind它“在很多方面像 view” 它在 rewriter 阶段改写成标准 relational query 权限类似 security invoker viewsecurity definer变体暂未实现
这意味着 PostgreSQL 的战略不是“造一个图库内核”，而是：
把图看作一种可声明的数据语义层，然后复用现有关系执行体系。
这件事背后的第一性原理是什么？
第一性原理 1：企业数据的事实存储，大多数时候首先仍是关系型
绝大多数企业核心数据，天然就是表：
用户 订单 商品 设备 账户 风控事件 组织结构 操作日志
所谓“图”，很多时候不是另一份数据，而是同一份关系数据的另一种观察方式。
节点是实体，边是关系，属性还是列。
如果图只是语义层，那么最合理的做法，往往不是复制一份物理存储，
而是在原始关系数据之上提供图查询表达能力。
第一性原理 2：多系统架构的成本，不会因为 PPT 上画得优雅就消失
每多一个数据库系统，你增加的不是一个产品 logo，而是一整套现实成本：
数据同步延迟 双写一致性 权限口径差异 审计链路断裂 运维和备份复杂度 团队技能栈分裂
所以如果 80% 的图需求，其实可以在关系世界内部解决，
那单独引入图数据库，本质上就是在为剩余 20% 的极端能力支付 100% 的系统复杂度。
这正是 SQL/PGQ 最有杀伤力的地方。
五、但别高兴太早：这不等于 PostgreSQL 从此就是原生图数据库
观点必须锋利，也必须克制。
如果有人看到这个 commit，就开始喊：
“以后别用图数据库了，PostgreSQL 全包了。”
那这个判断明显过头。
为什么？因为它现在的路线本质上还是：
图语义 + 关系改写。
这条路线的优势很明显：
统一存储 统一事务 统一权限 统一工具链 统一运维 更符合 SQL 标准
但它也有天然代价：
1. 图查询最终还是要落到关系执行计划上
这意味着复杂图模式匹配、多跳遍历、深层路径扩展，最后仍然要接受关系优化器和关系执行器的约束。
它未必不能做，
但不能天真地以为它会自动拥有专用图库那种“按图而生”的物理执行优势。
2. 复杂模式匹配的优化，不会因为语法变优雅就自动完成
语法层的 MATCH 很漂亮，
但底层是否能稳定地产生高质量 plan，是另一件事。
尤其图模式常常会引出：
多重 join 路径扩展 谓词下推难题 基数估计困难 执行代价爆炸
如果这些问题处理不好，
那“能写图查询”和“能高效跑图查询”，中间隔着完整一代优化器工作。
3. 这次提交发生在开发分支，不是当前稳定版的既有能力
这个时间点必须说清楚。
截至 2026 年 3 月 18 日，PostgreSQL 官方当前稳定文档仍然是 18 系列；这次 SQL/PGQ commit 发生在 2026 年 3 月 16 日 的开发分支上。
结合 CommitFest 页面显示其目标周期为 PG19-Final，这更像是面向未来大版本的主干能力，而不是今天生产环境里已经普及的现成选项。
所以正确表述应该是：
PostgreSQL 已经在主干方向上正式接纳 SQL/PGQ，但企业是否立刻上生产，还要看后续版本打磨、优化器成熟度和生态配套。
六、这事对架构最大的冲击，不是“多一个功能”，而是“中间地带被吃掉了”
图数据库真正稳固的护城河，从来不是“能表达图”，而是两件事：
超复杂图遍历性能 专用图模型与图算法生态
但现实里，企业大量所谓“图需求”其实处于中间地带：
关系明确，但不是超深遍历 要查关联链，但不一定要跑高级图算法 想统一治理，不想另建系统 开发团队 SQL 强，图库经验弱 业务更重一致性、审计、权限，而不是最极限的图性能
这类场景，才是 SQL/PGQ 最危险的猎物。
也就是说，PostgreSQL 不一定会先吃掉那些最 hardcore 的图库场景，
它更可能先吃掉的是：
原本因为“没有标准图查询入口”，才被迫外溢出去的那部分业务。
这和当年很多 JSON workload 回流关系数据库，是同一种历史逻辑。
七、一个真正有说服力的判断框架：什么时候你该用 PGQ，什么时候别自欺欺人
适合优先评估 SQL/PGQ 的前提
如果你满足以下前提，SQL/PGQ 很值得认真评估：
核心数据本来就在 PostgreSQL 图只是其中一种查询视图，而不是唯一数据模型 图查询深度有限，中等复杂度为主 强事务一致性、权限统一、备份恢复统一很重要 团队 SQL 能力强于图库专用方言能力 你更在意系统整体复杂度，而不是某类图遍历的理论最优
在这些前提下，SQL/PGQ 的价值不是“能省点开发时间”，
而是可能直接减少一整套系统边界。
不要自欺欺人的情况
如果你的场景是：
超深路径遍历是常态 图算法是主角，不是配角 工作负载几乎完全图中心化 需要专门围绕图结构做高性能存储和执行 关系模型只是顺带兼容
那你就别因为一个标准语法就误判形势。
这时候更合理的观点是：
SQL/PGQ 会提升 PostgreSQL 的图表达能力，但未必替代原生图引擎在极端图场景中的优势。
一旦这个前提成立，架构判断就不该是“要不要全换”，
而是“哪些图场景回归 PostgreSQL，哪些保留专用引擎”。
八、它为什么比你想象的更“标准化”？
这次还有一个常被低估的信号：
这不是某个厂商自造语法，而是SQL:2023 标准里的 SQL/PGQ。
这意味着什么？
意味着 PostgreSQL 这次不是在做“专有图扩展”，
而是在抢一个更高层的叙事权：
把图查询纳入标准 SQL 版图。
标准化的意义远不只是“文档更好看”，而是：
开发者心智成本更低 厂商绑定风险更低 工具链更容易跟进 教学、治理、审计语言更统一 企业采购与架构决策更容易保守化
一句话：
一旦图查询被标准 SQL 收编，它就更像“数据库通用能力”，而不再只是“某类专用产品卖点”。
这才是这件事最深层的产业含义。
九、别忽略一个现实信号：这不是轻量 patch，而是认真工程化推进
从 CommitFest 页面看，这个 patch 集规模达到 +15,263/-216 行，状态在 2026 年 3 月 10 日 已到 Ready for Committer；
而 2026 年 1 月的评审邮件还给出过一组很有代表性的质量信号：约 180 个测试用例、90.5% 行覆盖率。
这组数字不能证明“功能已经完美”，但至少说明两件事：
社区不是把它当玩具补丁处理 它已经进入系统性评审、测试、文档和工具配套阶段
对于一个全新对象类型和新查询范式来说，这种工程投入本身就是重要信号。
十、我的判断：这件事会先改变企业架构，而不是先改变学术定义
最后给一个明确判断。
SQL/PGQ 进入 PostgreSQL 主干，短期内最先改变的，不会是图数据库教科书，而是企业技术选型的默认答案。
过去很多项目一提“关系网络、路径查询、主数据关联、供应链关联、风控团伙、血缘分析”，
默认动作就是：
“是不是该上个图库？”
而未来更可能变成：
“先看这事能不能在 PostgreSQL 里用 SQL/PGQ 解掉，再决定要不要多一套系统。”
这就是决定性的变化。
它不一定会立刻终结图数据库。
但它很可能先终结大量其实没必要上独立图库的项目。
这比“替代谁”更现实，也更重要。
结论
这次 SQL Property Graph Queries (SQL/PGQ) 提交，真正值得记住的不是 GRAPH_TABLE 这几个字，
而是它背后的路线：
PostgreSQL 正在尝试把“图”从独立数据库品类，重新拉回 SQL 标准和关系系统主场。
如果这条路成熟，最先被改写的将是三件事：
企业对“图需求必须上图库”的默认认知 关系库与图库双轨架构的成本合理性 开发者对图查询必须学习另一套语言、另一套系统的心理预期
但同时也要清醒：
SQL/PGQ 扩大的是 PostgreSQL 的图能力边界，不等于它自动获得原生图引擎在所有极端场景下的物理优势。
所以最成熟的态度不是站队，
而是重新做一遍架构分层：
中等复杂度图查询，是否可以回归 PostgreSQL 极端图遍历和图算法，是否仍保留专用引擎 单系统治理收益，是否已经超过多系统分裂的成本
这才是这次 commit 真正逼你回答的问题。
你怎么看
如果 PostgreSQL 在未来版本里把 SQL/PGQ 打磨成熟，你们团队会把哪些图场景收回 PostgreSQL，哪些仍留给专用图库？
你更看重“统一数据平台、统一运维”，还是“专用图引擎的极致能力”？
评论区聊聊：SQL/PGQ 进 PostgreSQL，究竟是在补齐短板，还是在重画数据库边界？