作者惜元01 背景知识一个反常识的现象正在发生Agent 到底需要什么样的数据库这个问题现在每家厂商都有答案而且答案出奇一致地指向自家产品向量数据库说 Agent 的记忆就是 embedding图数据库说知识本质上是关系NewSQL 说弹性多租户才是刚需。自卖自夸听多了不妨先放下论点看看市场实际选了什么。Lovable 给每个 workspace 自动配一个 Supabase 后端——也就是 PostgreSQLAgent 不光建表连 RLS 权限策略都是它配的[1]Bolt、Figma Make 的后端集成同样指向 Supabase[2][3]Supabase 因为被这批 AI Builder 集体当成默认后端估值已经上百亿美金[4]。Replit Agent 检测到应用需要存数据会自动开一个 Neon 的 PostgreSQL[5]连把应用回滚到几天前这种功能都是拿 Neon 的 copy-on-write 分支做的[6]。Databricks 收购 Neon 的公告里给过一个数字Neon 平台上超过 80% 的数据库已经由 AI Agent 自动创建[7]而 2023 年 10 月这个比例还只有 0.1%[8]——不到两年从忽略不计涨到绝对多数这笔收购的价码媒体普遍报道在十亿美金上下[9]。边缘侧Cloudflare 的 Agents SDK 干脆给每个 Agent 实例内置一个 SQLite跑在 Durable Object 里官方文档的说法是事实上零延迟的读写[10]。把这张清单摊开看有个事实几乎扎眼跑得最快的这批 Agent 建站产品不管前端多花哨、商业模式多激进数据底座几乎清一色收敛到了 PostgreSQL 上剩下的零星份额也在 SQLite 这种同样古老的方言手里。没有一家把向量数据库当底座没有一家选 MongoDB更没有谁发明新接口。有意思的地方在于PostgreSQL 几乎没有一项是单项冠军——论分布式不如人论向量检索规模不如专用引擎论嵌入式轻巧不如 SQLite。那它凭什么赢这不是巧合也不是营销的结果。当我们拆解这批头部 Agent 项目的架构后发现了一个残酷的真相Agent 时代的数据库选型终局裁判不是人类架构师而是语言模型的语料引力。要理解这个结论需要先接受一个观念转变Agent 是一种全新的数据库客户端。过去三十年数据库比的是 TPS、延迟、单机容量、扩展性。因为用户是人类工程师人会读文档、会绕坑、会在 schema 设计上深思熟虑。现在数据库迎来了一类全新的客户端Agent。它不读文档至少不像人那样读它靠的是训练时见过的东西它不深思熟虑它横冲直撞地试错它还会被注入、会犯傻。客户端换了评判数据库的标准整个换了一套只是大部分讨论还没跟上。本文将深度解析 PostgreSQL 胜出的 5 个底层逻辑以及在实际落地中如何避开那些看起来很美的选型陷阱。02 技术深度PostgreSQL 胜出的 5 个底层逻辑2.1 语料密度与方言漂移LLM 的“母语”是 SQL先说我觉得最被低估的一条。你有没有注意到Agent 写 PostgreSQL 顶多在查询逻辑上犯错跑一下、看报错、自己就修了但写某些新兴数据库的 DSL它会成段地编造不存在的 API——而且编得理直气壮这不是错觉是有实证研究的模型生成常用第三方库的 API 时平均幻觉率约 13%而面对训练语料覆盖不到的 API幻觉率高达 85%[11]另一项研究还发现模型面对不熟悉的库时会径直无视你的描述退回它熟悉的那一小撮库[12]。原因很简单模型操作数据库的能力不是现场学的是训练时从三十年的 Stack Overflow、技术博客、开源项目代码里内化进权重的。文档只是这个语料库里很小的一部分。真正的指标不是“文档全不全”而是语料密度这个东西被公开讨论了多少年、多少量、离今天多近、有多少真实代码晒在外面。 按这个标准SQL 是 LLM 的母语而 PostgreSQL 方言大概是母语里的普通话。这里有个反直觉的推论。Oracle 是闭源的但 LLM 写起 Oracle 来明显比写那些新兴数据库的 DSL 熟练得多——三十年企业开发攒下的公开讨论摆在那里。当然按语料成色推断它大概率还是不如 PostgreSQLOracle 的语料偏老海量企业 PL/SQL 代码又是私有的、进不了训练集多方言基准 BIRD-CRITIC 的实测也确实显示模型的 SQL 能力对具体方言有显著依赖[13]。你看连“语料的成色”都在影响排名这更说明问题了。反过来不少新数据库文档写得很漂亮Agent 用起来照样瞎编——文档再好没有成千上万人在公开场合用过、踩过坑、吵过架模型对它的掌握就是浅的。比语料贫乏更要命的是另一种东西方言漂移。市面上有大量“兼容 95% PostgreSQL/MySQL”的魔改产品对人类来说 95% 够用了剩下 5% 看文档就行。但 Agent 会满怀信心地把原版知识套上去然后恰好在那 5% 上写出看起来对、实际错的查询。完全陌生的数据库反而安全——Agent 知道自己不会会去查魔改库的问题是 Agent 不知道自己不会。所以我的判断是兼容 XX 协议这句营销话术在 Agent 时代会被残酷地检验要么 100% 兼容要么就是陷阱。顺着这个逻辑还有一条接口稳定性。PostgreSQL 十年前的 SQL 今天还能跑。对人类工程师这叫无聊对 Agent 这叫资产——模型权重里的知识永不过期。而那些每个大版本都重做一遍 API 的项目对人类叫技术活力对 Agent 叫知识折旧。2.2 试错安全网事务性 DDL 与 copy-on-write 分支Agent 干活的方式跟人类完全不同。人是想清楚再动手Agent 是动手了再想写个查询看看结果不对就换个写法建个表试试不行就删了重来。它的工作方式天然是试错式的而且它不心疼推倒重来——失败的分支说扔就扔。这种工作方式让两个过去不太被当卖点的内核特性突然变得值钱。一是事务性 DDL。很多人不知道 PostgreSQL 的建表、改列是可以回滚的[14]——Agent 在一个事务里尝试一组 schema 变更错了整体撤销数据库干干净净。MySQL 呢每条 DDL 都会隐式提交事务[15]——8.0 之后单条 DDL 自身是原子的但一组迁移走到第三步失败前两步已经落了地、回不去Agent 下一轮还得先收拾残局。二是廉价分支。Neon 在 PostgreSQL 存储层做的 copy-on-write 分支让 Agent 可以“开个沙箱随便折腾跑通了留下跑不通整个扔掉”。前面提到 Replit “把应用回滚到几天前”的功能本质上就是 Neon 分支能力的产品化封装——Agent 可以在数据库存储层拥有 Git 般的分支/合并/回滚语义代价是几毫秒的元数据操作而不是几分钟的数据拷贝。这两样东西对人类是锦上添花对 Agent 是安全网。2.3 自省能力与安全边界pg_catalog 与 RLS还有一件小事做 Agent 产品的人应该都有体会Agent 接手一个数据库第一件事是摸清里面有什么。人有设计文档和同事可以问Agent 只能问数据库本身。这时候pg_catalog的完备性就显出来了——表、列、索引、约束、统计信息、连注释都是可以用 SQL 查的关系数据等于数据库自带一份永远和实际状态一致的机读文档。安全这块我只说一句Agent 会被提示注入会犯傻所以权限边界必须落在数据库层别指望 system prompt 里写一句“请不要删除生产数据”。PostgreSQL 的行级安全RLS在这里非常实用——每个 Agent 一个 role安全策略附着在表上任何查询路径都绕不过去。这个能力在主流开源库里还真就 PostgreSQL 做得最完整。2.4 一库多模扩展架构才是最深的护城河一个真实的 Agent 系统至少同时产生四类数据记忆要精确增删改查、要能追溯来源、知识要全文加向量的混合检索、业务数据要事务、轨迹日志要便宜地一直写。如果每类数据上一套专用系统你就得运维四个数据库、维护三条同步链路——而且 Agent 自己也得学四套接口。少跨一个系统就少一类 bug这对生成代码的成功率是实打实的影响。PostgreSQL 能用一个引擎吃下这些负载靠的不是堆功能而是内核的扩展架构自定义类型、自定义索引访问方法、FDW、后台 worker内核把扩展点都留好了。pgvector 不是外挂的兼容层它是以原生索引HNSW的身份接进查询规划器的——向量检索可以和 SQL 谓词、JOIN、事务在同一个执行计划里跑。我喜欢的说法是PostgreSQL 吸收新负载的方式是长出新器官而不是绑上假肢。全文检索之于 ParadeDB、时序之于 Timescale、地理之于 PostGIS全是同一个机制。这意味着下次 Agent 又冒出什么新的数据需求PostgreSQL 生态的响应方式还是写个扩展——方言不变模型已有的知识继续有效。2.5 供给侧的解耦方言层与实现层分开演进回到开头 Databricks 那笔收购那个 80% 其实还有第二层含义值得单独拎出来说在平台型场景里Agent 已经不只是数据库的使用者还是数据库的批量创造者。Lovable 披露过2025 年年中平台上每天新建的项目就超过了 10 万个[19]其中要存数据的每一个都需要自己的库。这时候一批过去属于运维层的指标突然升格成了一级需求provisioning 如果要几分钟Agent 就得在生成的代码里写 retry/poll 那一套基础设施的慢会直接污染生成代码的质量海量长尾站点绝大多数几乎没有流量但全都要求在线按真实实例分配资源成本直接爆炸所以秒级创建、scale-to-zero、租户故障隔离一个都不能少。做平台的团队大多绕不开同一道算术题单实例塞上万个 schema系统目录、连接数和 autovacuum 会先撞墙给每个租户开一个托管实例账面上又根本算不下来。但有两点冷静的要补。第一这是 Agent 平台的需求不是所有 Agent 场景的需求——企业内部 Agent、Coding Agent、个人助理的记忆库哪来的千万租户把平台场景的标准推广成整个赛道的标准是有点过了。第二供给侧之争和方言之争是正交的而且 PostgreSQL 在供给侧的牌比很多人以为的好。具体说PostgreSQL 18 新增了file_copy_method参数CREATE DATABASE走STRATEGY FILE_COPY时把它设成 clone底层会换用copy_file_range/clonefile这类系统调用在 XFS开启 reflink、Btrfs、APFS 这类写时复制文件系统上建库就退化成一次文件克隆[20]。预置一个带完整 schema 和种子数据的模板库每个新租户的库近乎瞬时地克隆出来初始磁盘占用接近零没改过的数据块一直物理共享[21]。也就是说“每个 Agent 一个独立 database、秒级创建、随便折腾、用完即弃”原版 PostgreSQL 就能做到一步都不用离开方言。当然天花板也得说实话所有租户共享一个实例的系统目录、连接和 autovacuum到万级租户量级会撞墙再往上要么实例分片加路由要么下沉到 Neon 那种存算分离的存储虚拟化或者阿里云 RDS PostgreSQL Serverless这类云原生实现。但注意这条从单机到平台的升级路径上每一步 Agent 看到的都是同一个 PostgreSQL——物理层在变方言和心智模型从不漂移。这就是我说“解耦”的意思Agent 时代数据库的方言层和实现层分开了。我说 PostgreSQL 是最佳选择严格说是 PostgreSQL 的方言和心智模型是最佳选择物理层你可以用单机、用 reflink 克隆的多租户单实例、用页服务器虚拟化的云原生实现随便。供给侧谁的虚拟化更便宜这个竞争是真实的但无论物理层怎么创新接口层都在收敛回 LLM 最熟的那几门方言——你看连分布式数据库厂商进 Agent 场景也老老实实讲 MySQL 或 PostgreSQL 方言而不是发明新接口。没人能对抗语料引力。03 实际应用候选者对比、代码示例与避坑指南3.1 候选者对比为什么其他数据库不是选项理论讲完了我们把主要候选者放到 Agent 底座这个具体场景里过一遍。MySQL 语料密度跟 PostgreSQL 同级这是它最硬的牌。但往下看每一项都矮半头没有事务性 DDLAgent 试错代价大扩展机制弱多模负载得外挂RLS 缺失安全边界只能上层做原生向量类型到 MySQL 9 才引入[16]——起步晚了 pgvector 好几年生态成熟度差距明显。MongoDB 的问题在于查询接口聚合管道的公开语料体量远小于 SQL按前面说的语料密度规律模型写它就是更生疏而且 SSPL 许可证没有通过 OSI 认证严格说它已经不算开源软件了[17]。做企业选型时这一条会直接砍掉合规评估。专用向量库我认为窗口正在关闭——工业界效果好的检索普遍是混合检索BM25、向量召回再加重排的组合在公开实验里明显优于单一向量检索[18]pgvector 在一个执行计划里就能和全文检索、结构化过滤组合独立向量库还得再外配全文引擎和元数据存储。它剩下的合理战场是十亿级向量的检索服务那是搜索基础设施不是 Agent 底座。图数据库就更窄了。Agent 记忆里的图查询大多是“实体周围两三跳”PostgreSQL 的递归 CTE 完全够用而 Cypher 的公开语料量跟 SQL 完全不在一个数量级——按语料引力的逻辑模型写图查询天然吃亏。至于真正需要深度图算法的场景推荐、风控那是分析型任务不是 Agent 实时决策路径上的东西。SQLite 要单独说因为它不是对手是搭档。“每个 Agent 一个 SQLite 文件”是我很喜欢的形态一个 Agent 一辈子的记忆也就几百 MB单文件天然隔离备份迁移删除都是文件操作Agent 可以把它当私有大脑随便建表。Cloudflare Agents SDK 干脆给每个 Durable Object 内置一个 SQLite[10]——同一台边缘节点上代码和数据在一个进程里读写延迟接近零。它的边界在并发写和平台规模下的备份高可用——所以我的定位是 PostgreSQL 为中心SQLite 为端。一句话总结候选者语料密度扩展性事务性 DDLRLS一句话结论PostgreSQL★★★★★★★★★★✓✓中心底座SQLite★★★★☆★★☆☆☆✓✗边缘搭档MySQL★★★★★★★☆☆☆✗✗语料够但内核弱MongoDB★★★☆☆★★★☆☆✗✗语料少许可争议专用向量库★★☆☆☆★☆☆☆☆✗✗混合检索时代已过窗口期图数据库★☆☆☆☆★★☆☆☆✗✗Cypher 语料量差 SQL 一个数量级3.2 代码示例Agent 用得上的两个 PostgreSQL 特性示例一事务性 DDL——让 Agent 的试错干净落地Agent 在生成迁移脚本时一次尝试可能包含多条 DDL。用事务包起来失败就整体回滚避免半成品污染 schemaBEGIN; -- Agent 尝试为 Agent 记忆表添加 JSON 上下文列和 GIN 索引 ALTER TABLE agent_memory ADD COLUMN context_json JSONB; CREATE INDEX idx_context ON agent_memory USING GIN (context_json); -- 如果这里任何一步报错比如列名冲突、索引资源不足 -- 整个事务回滚agent_memory 表回到修改前的状态 COMMIT;MySQL 里同样的操作第一步ALTER TABLE一执行就已经隐式 commit 了第二步失败也回不去。Agent 下一轮就得先写一段检查列是否存在存在就跳过的防御代码——问题层层堆积。示例二行级安全RLS——让权限边界落在数据库层多租户 Agent 系统里一个 Agent 只应该看到属于自己 workspace 的数据。别把这个约束放在应用层Agent 会被 prompt injection 绕开。放在数据库层任何查询路径都绕不过去-- 为 Agent 创建独立 role CREATE ROLE agent_user WITH LOGIN PASSWORD secret; -- 开启 RLS 并绑定策略 ALTER TABLE workspace_data ENABLE ROW LEVEL SECURITY; CREATE POLICY agent_isolation ON workspace_data USING (workspace_id current_setting(app.current_workspace_id)::uuid); -- Agent 连接时设置当前 workspace之后所有查询自动只看该 workspace 数据 SET app.current_workspace_id ws-abc-123; SELECT * FROM workspace_data; -- 只返回 workspace_id ws-abc-123 的行即使 Agent 被诱导写出DELETE FROM workspace_data WHERE 11RLS 策略也会把删除范围限制在当前 workspace 内——最坏情况是删了自己那份不会污染其他租户。3.3 避坑指南PostgreSQL 的 5 个局限与解法公平起见把代价也摆出来。PostgreSQL 也不是没毛病连接模型每连接一个进程Agent 系统偏偏喜欢大量短连接。解法PgBouncer 或云厂商自带的连接池是必需品不是可选项。全文检索原生不是 BM25排序质量打不过 Elasticsearch。解法严肃检索靠 ParadeDB 补或用云厂商 RDS PG 内置的中文分词扩展搭配 pgvector 做混合检索。向量规模pgvector 到十亿级向量、高 QPS 顶不住。解法那已经出了“Agent 底座”的范畴属于搜索基础设施——单独拉一套向量引擎PG 只存元数据。Vacuum 调优高频更新负载下的老问题。解法合理设置 autovacuum 参数或用云原生 PG 数据库。万级租户天花板单实例共享系统目录、连接和 autovacuum。解法实例分片加路由或下沉到存算分离的云原生实现。关键是——这五条全是运维层的债Agent 感知不到它们的存在。它们不污染查询层不消耗模型权重里的任何知识。这跟“方言有坑”是两种性质完全不同的问题。运维层的债可以运维层还方言层的坑只能推翻重来。04 总结终局的裁判是一个语言模型最后说一个带时间箭头的判断。Agent 默认写 PostgreSQL 方言 → 新项目就更倾向选 PostgreSQL → 于是产生更多 PostgreSQL 语料 → 下一代模型就更擅长 PostgreSQL——这是个自我强化的飞轮。Agent 时代的数据库市场会强者愈强新数据库的冷启动难度比从前高了一个数量级它不仅要说服开发者还要说服模型权重。前者靠营销预算还能使使劲后者只能靠日积月累的公开语料没有捷径。所以这个结论其实不是我选出来的也不是哪家厂商营销出来的。PostgreSQL 是被四十年的公开语料、一个从不漂移的方言、和一套恰好为多模负载留好扩展点的内核架构共同选出来的——开头那张全球清单不过是这个飞轮转到今天的一帧快照。如果你要从这篇文章带走三句话语料密度决定 Agent 的数据库能力上限——文档再好没用得有几十年公开代码晒在外面兼容 95% 是陷阱——Agent 不知道自己不会方言漂移必然翻车中心 PostgreSQL、边缘 SQLite——这是 Agent 时代数据库形态的稳定解数据库战争打了三十年谁能想到终局的裁判是一个语言模型。05 写在最后方向清楚了但从“开源 PG”到“生产级 Agent 平台”之间还有一段工程量Supabase 要自己搭、知识图谱要自己建、Agent 沙箱执行环境要自己搞。我们团队最近在阿里云 RDS PostgreSQL 之上做了点尝试把这些组件整合成了一套开箱即用的 Agent 开发平台在 PostgreSQL 基础能力之上进一步增强了多租户隔离、数据分支、向量检索和图关系分析等能力因此非常适合作为云上 Agent 应用的核心数据底座。如果你正在做 Agent 应用欢迎顺手看看平台地址阿里云 RDS PostgreSQL Agent 开发平台RDS PG 技术交流钉群103525002795参考资料[1] SupabaseLovable Cloud Supabase https://supabase.com/blog/lovable-cloud-launch[2] SupabaseSupabase for AI BuildersBolt、Figma、Lovable、Replit 集成 https://supabase.com/solutions/ai-builders[3] SupabaseCreate a Supabase backend using Figma Make https://supabase.com/blog/figma-make-support-for-supabase[4] TechTimesOpen-Source Database Supabase Hits $10.5 Billion https://www.techtimes.com/articles/317950/20260607/open-source-database-supabase-hits-105-billion-ai-coding-boom-mints-new-decacorn.htm[5] NeonLooking at How Replit Agent Handles Databases https://neon.com/blog/looking-at-how-replit-agent-handles-databases[6] NeonReplit App History, Powered by Neon Branches https://neon.com/blog/replit-app-history-powered-by-neon-branches[7] Databricks 收购 Neon 官方公告超过 80% 的数据库由 AI Agent 自动创建 https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-neon-help-developers-deliver-ai-systems[8] SaaStr 引述 Databricks《State of AI Agents》报告2023 年 10 月为 0.1% https://www.saastr.com/databricks-only-19-of-organizations-have-deployed-ai-agents-but-theyre-already-creating-97-of-databases/[9] InfoWorldDatabricks to acquire open-source database startup Neon https://www.infoworld.com/article/3985947/databricks-to-acquire-open-source-database-startup-neon-to-build-the-next-wave-of-ai-agents.html[10] Cloudflare Agents 文档Store and sync state https://developers.cloudflare.com/agents/api-reference/store-and-sync-state/[11] 论文Towards Mitigating API Hallucination in Code Generated by LLMs https://arxiv.org/abs/2505.05057[12] 论文Library Hallucinations in LLMs: Risk Analysis Grounded in Developer Queries https://arxiv.org/abs/2509.22202[13] 论文与基准SWE-SQL / BIRD-CRITIC 多方言 SQL 基准 https://arxiv.org/abs/2506.18951[14] PostgreSQL 官方文档Transactional DDL https://www.postgresql.org/docs/current/sql-begin.html[15] MySQL 官方文档Statements That Cause an Implicit Commit https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html[16] MySQL 9.0 Release NotesNative Vector Data Type https://dev.mysql.com/doc/relnotes/mysql/9.0/en/[17] Open Source InitiativeSSPL is Not an Open Source License https://opensource.org/blog/the-sspl-is-not-an-open-source-license[18] 论文Hybrid Retrieval outperforms Dense-Only Retrieval https://arxiv.org/abs/2304.04443[19] Lovable 官方数据Daily Project Creation Statistics https://lovable.dev/blog/scaling-milestones[20] PostgreSQL 18 Release Notesfile_copy_method parameter https://www.postgresql.org/docs/18/release-18.html[21] PostgreSQL 18 文档CREATE DATABASE with clone strategy https://www.postgresql.org/docs/18/sql-createdatabase.html