本文整理于 HOW 2026 演讲内容演讲者萧少聪前 PostgreSQL 分会会长及中文社区主席、IvorySQL 专家顾问委员。过去的两年里我一直坚信一个判断在我们现在用 AI 方法、用大语言模型进行开发的模式下PostgreSQL 一定会成为任何一个 AI 项目的首选搭配。当然我不是说 PG 可以包打天下、做永远的底座——到了某个时间点某些工作负载、某些业务场景确实可能需要把特定形态的数据迁移到专用的数据库上。但作为起点PG 毋庸置疑是最佳选择。今天我会分四个话题来展开第一是我们的烦恼——Token 焦虑第二是One SQL如何让你事半功倍第三是统一数据面如何让 AI无死角地工作第四是讨论一下 PG 作为 AI 首选的边界在哪里。一、Vibe Coding 的烦恼系统复杂度带来的Token 焚化炉我们通常开发一个系统的时候一开始一个数据库就足够了业务不会那么复杂。但在应用过程中——不管你是开发 AI 应用还是其他应用——你会发现我需要 JSON 功能我需要搜索功能我需要 AI 相关的各种能力。每一次增加都是一种新的业务形态每一个决策在当下看起来都是非常正确和合理的。但结果是什么你的系统会从 1 个数据库变成 5 个甚至更多。你引入了 MongoDB 处理文档引入了 Elasticsearch 处理搜索引入了 Milvus 处理向量——看上去你很负责任为团队选择了业界最好的产品。但大家要想一个问题你的业务上去了吗项目可能才刚刚开始你一下子就拿了一个最复杂的架构这其实并不合适。更重要的是在 Vibe Coding 的过程中多数据库带来的代价是Token 的急剧膨胀不同数据库有不同的语法AI 要学习多套查询语言数据需要在多个系统间同步AI 要编写和维护 ETL 逻辑跨系统的查询被拆分成多个步骤每一步都要消耗 Token上下文窗口被撑爆模型直接降智变傻这哪里是 Vibe Coding这简直是Token 焚化炉。解决方案是什么在一个边界之内用同一个数据库去解决所有问题。而这个数据库就是 PostgreSQL。二、One SQL事半功倍10 天 5 万行的实战验证去年 11 月我做了一个实验用纯 AI 辅助开发的方式在 10 天内完成了一个名为 OntologyAlpha 的项目总共生成了约 5.4 万行代码最终上线有效代码约 1.13 万行。这个项目是个本体论Ontology相关的系统底层需要处理四类数据JSONAI 的输入输出前后端交互信息向量文本的语义化表达用于相似搜索图知识点上下游的关联追踪和分层管理时序上下文沟通的前后顺序记录项目架构上存储层就是PostgreSQL 原生多模态存储上面是 Async Workers 和 Python 安全沙箱再上面是 Next.js 可视化工作台——全部代码由 AI 生成我自己没有写一行。开发方式我用 Google AI Studio 的 Gemini 模型担任首席数据官/CTO负责架构规划和任务拆分然后用 Cursor免费默认模型进行具体代码实现。总投入 82 个工时大约 10 个人天。实现效果CPU/内存设备监控支持精准搜索和模糊语义搜索小学数学课本知识向量化形成知识图谱没有用专用图数据库而是用两张关系表模拟图结构PDF 文档如新加坡人才政策自动抽取关键词和业务关联关系形成上下游链路Python 沙箱联动CPU 过热时自动触发上游链路状态变更关键的 SQL 长这样-- 一条SQL同时完成JSON提取 关系型图遍历 向量相似度搜索SELECT...FROM...WHEREname-xxx...-- JSON字段提取ANDrelation_type...-- 关系型图逻辑ANDembedding-...-- 向量相似度一条 SQL搞定三种数据模型的联合查询。在 PG 里面事务、权限、备份全是一套体系不用操心跨系统的数据一致性问题。整个开发过程我用的都是最基础的 AI 套餐——Google Gemini 20 美元/月Cursor 免费套餐。Token 消耗非常可控。三、统一数据面快人一步AI 的无死角覆盖很多人吐槽说 PostgreSQL 做向量不行——内存消耗太大难以扩展到亿级数据。这里我要推荐一个项目pgvectorscale由 TimescaleDB 团队开发。它把向量索引放到磁盘上通过 DiskANN 量化技术突破了内存限制支持超大规模向量检索的同时大幅降低成本。但我想强调的是PG 的优势不在于单项做到最强。你的系统如果必须处理超过 1 亿级别的向量、超高 QPS那确实要选专用向量数据库。但当你的业务需要对关系型、向量、JSON、时序、图等多种数据模型进行组合管理时PG 是一个各项能力都在 80 分左右的全能选手。组合后的优势是什么极大地减少系统拆分显著降低开发与运维复杂度。在多数据库混合架构下你的应用程序要自己管理关系库用 SQL向量库可能根本写不了 SQL两个系统之间要不要事务怎么保证一致性引入 ETL 后应用程序要关注 ETL 延迟哪些数据可信、哪些已过期权限怎么统一备份怎么统一这套东西全部管起来Vibe Coding 的消耗量、准确度、产出效果都会变得非常糟糕。而在 PG 里面统一数据面的价值在于1 次 Network Hop应用只访问一个数据库1 套事务所有操作在同一事务中完成1 套权限统一的数据访问控制1 套备份统一的容灾体系系统复杂度带来的损耗往往大于纯粹的单点性能收益。很多时候你是在为多系统架构买单。四、PG 是 AI 的爱的首选有边界更放心我这么喜欢 PG那什么时候应该考虑引入专用数据库我自己的建议是这样的——先用 PG 解决 80%的问题快速形成业务能力。等赚到第一块钱了再考虑要不要迁移。具体来说数据类型PG 能撑到什么程度何时考虑迁移向量亿级以下、中等 QPS向量规模爆发至亿级且 QPS 极高时时序常规的日志/埋点/监控数据量巨大且有特殊压缩需求时JSON绝大多数场景遇到数千行的超大 JSON 或高频更新时图3~4 层深度的浅层关联图的深度和复杂度超出 PG 处理能力时明确边界反而更敢用。PG 19 会原生支持更好的图查询。现阶段你也可以用 AGE 插件或者像我一样用几张关系表把图结构糊出来——对于大多数 AI 应用场景这完全够用。结语更少的系统而不是更强的系统在 AI 时代我觉得每个人都应该是一个架构师。但从架构的思维来看目标应该是更少的系统而不是更强的系统。以前有一种想法我把架构做得越复杂老板越不敢开掉我。但今天 AI 来了老板想开你也不是因为 AI而是因为经营不善。我们不要有这种负担。真正有价值的是PostgreSQL 是默认的起点而不是终点。用 PG 起步快速验证商业模式节省 Token节省管理时间把精力放在业务变现上。等到业务稳定盈利了、遇到明确的技术瓶颈了再谨慎地评估是否引入专用数据库。干净简洁的架构才是未来弹性最大的架构。