烂人不配爱如果你维护的 PostgreSQL 库跑着几万张表，突然有一天业务方拿着一堆“关系链条”的需求找上门，比如股权穿透好几层、用户之间关联到两度以上、设备背后串起来一堆账号，那你大概率体会过递归 CTE 写到怀疑人生是什么感觉。这种需求本质上是在问“图”，而成熟的关系型数据库对图遍历的支持一直很别扭。Apache AGE 就是冲着这个痛点来的：它让 PostgreSQL 直接具备图数据库能力，不用迁移数据、不用另起一套集群，就能用 openCypher 语言做图查询。
这篇内容我会按一个完整项目的引入过程来写：为什么需要图数据库化、AGE 的底层原理、从编译安装到建图写入的完整步骤、一个企业关联图谱的实操案例，以及我在实际落地中踩过的坑。适合两类读者：一类是已经在用 PostgreSQL、想低成本引入图能力的团队；另一类是正在对比“要不要单独上 Neo4j 或图数据库服务”的架构师。看完你至少能判断 AGE 适不适合你的场景，也能照着步骤跑通一套可用的图查询环境。
1. 为什么要把 PostgreSQL 变成图数据库
1.1 关系模型擅长“存关系”，却不擅长“查关系”
很多刚接触图数据库的人会有个困惑：关系型数据库不就叫 relational database 吗，它存的难道不是关系？这里的关键区别是：关系模型里的“关系”指的是表与表之间的外键关联，它擅长的是通过 JOIN 把两三种数据关联起来；可一旦链条拉长，比如“找出 A 公司通过多层控股最终控制的所有公司”，问题就完全变了。你要么写一堆 UNION 把每层查询拼起来，要么用递归 CTE 自己控制深度，查询写出来又长又难调。
我自己接过一个实际需求：查出某个人在两跳以内关联到的所有企业。用 SQL 拆解，第一层是任职关系，第二层是股东关系，中间还要过滤重复，递归 CTE 写了差不多 80 行。换成正向图模型，用 openCypher 写就是一句 MATCH (p:Person)-[*1..2]->(c:Company) RETURN DISTINCT c。这种差距不是开发者能力问题，而是关系型模型在“遍历路径”这个场景下天生吃亏。
电商风控、社交推荐、企业治理、权限网络这类业务，本质都是图问题。你当然可以用关系表加递归慢慢磨，但图查询语言的出现就是为了让这类逻辑表达得更自然，也让执行引