为什么我说PostgreSQL是Agent Database的最佳选择

作者：惜元

01 背景知识：一个反常识的现象正在发生

Agent 到底需要什么样的数据库？这个问题现在每家厂商都有答案，而且答案出奇一致地指向自家产品：向量数据库说 Agent 的记忆就是 embedding，图数据库说知识本质上是关系，NewSQL 说弹性多租户才是刚需。自卖自夸听多了，不妨先放下论点，看看市场实际选了什么。

Lovable 给每个 workspace 自动配一个 Supabase 后端——也就是 PostgreSQL，Agent 不光建表，连 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 熟练得多——三十年企业开发攒下的公开讨论摆在那里。当然，按语料成色推断，它大概率还是不如 PostgreSQL：Oracle 的语料偏老，海量企业 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 同级，这是它最硬的牌。但往下看每一项都矮半头：没有事务性 DDL（Agent 试错代价大），扩展机制弱（多模负载得外挂），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 为端。

一句话总结：

3.2 代码示例：Agent 用得上的两个 PostgreSQL 特性

示例一：事务性 DDL——让 Agent 的试错干净落地

Agent 在生成迁移脚本时，一次尝试可能包含多条 DDL。用事务包起来，失败就整体回滚，避免半成品污染 schema：

BEGIN;
-- 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 1=1，RLS 策略也会把删除范围限制在当前 workspace 内——最坏情况是删了自己那份，不会污染其他租户。

3.3 避坑指南：PostgreSQL 的 5 个局限与解法

公平起见把代价也摆出来。PostgreSQL 也不是没毛病：

1. 连接模型：每连接一个进程，Agent 系统偏偏喜欢大量短连接。解法：PgBouncer 或云厂商自带的连接池是必需品，不是可选项。
   
2. 全文检索：原生不是 BM25，排序质量打不过 Elasticsearch。解法：严肃检索靠 ParadeDB 补，或用云厂商 RDS PG 内置的中文分词扩展搭配 pgvector 做混合检索。
   
3. 向量规模：pgvector 到十亿级向量、高 QPS 顶不住。解法：那已经出了“Agent 底座”的范畴，属于搜索基础设施——单独拉一套向量引擎，PG 只存元数据。
   
4. Vacuum 调优：高频更新负载下的老问题。解法：合理设置 autovacuum 参数，或用云原生 PG 数据库。
   
5. 万级租户天花板：单实例共享系统目录、连接和 autovacuum。解法：实例分片加路由，或下沉到存算分离的云原生实现。
   

关键是——这五条全是运维层的债，Agent 感知不到它们的存在。它们不污染查询层，不消耗模型权重里的任何知识。这跟“方言有坑”是两种性质完全不同的问题。运维层的债可以运维层还，方言层的坑只能推翻重来。

04 总结：终局的裁判是一个语言模型

最后说一个带时间箭头的判断。

Agent 默认写 PostgreSQL 方言 → 新项目就更倾向选 PostgreSQL → 于是产生更多 PostgreSQL 语料 → 下一代模型就更擅长 PostgreSQL——这是个自我强化的飞轮。

Agent 时代的数据库市场会强者愈强，新数据库的冷启动难度比从前高了一个数量级：它不仅要说服开发者，还要说服模型权重。前者靠营销预算还能使使劲，后者只能靠日积月累的公开语料，没有捷径。

所以这个结论其实不是我选出来的，也不是哪家厂商营销出来的。PostgreSQL 是被四十年的公开语料、一个从不漂移的方言、和一套恰好为多模负载留好扩展点的内核架构共同选出来的——开头那张全球清单，不过是这个飞轮转到今天的一帧快照。

如果你要从这篇文章带走三句话：

1. 语料密度决定 Agent 的数据库能力上限——文档再好没用，得有几十年公开代码晒在外面
   
2. 兼容 95% 是陷阱——Agent 不知道自己不会，方言漂移必然翻车
   
3. 中心 PostgreSQL、边缘 SQLite——这是 Agent 时代数据库形态的稳定解
   

数据库战争打了三十年，谁能想到，终局的裁判是一个语言模型。

05 写在最后

方向清楚了，但从“开源 PG”到“生产级 Agent 平台”之间还有一段工程量：Supabase 要自己搭、知识图谱要自己建、Agent 沙箱执行环境要自己搞。

我们团队最近在阿里云 RDS PostgreSQL 之上做了点尝试，把这些组件整合成了一套开箱即用的 Agent 开发平台，在 PostgreSQL 基础能力之上，进一步增强了多租户隔离、数据分支、向量检索和图关系分析等能力，因此非常适合作为云上 Agent 应用的核心数据底座。如果你正在做 Agent 应用，欢迎顺手看看：

• 平台地址：阿里云 RDS PostgreSQL Agent 开发平台
  
• RDS PG 技术交流钉群：103525002795

参考资料

[1] Supabase：Lovable Cloud + Supabase https://supabase.com/blog/lovable-cloud-launch

[2] Supabase：Supabase for AI Builders（Bolt、Figma、Lovable、Replit 集成） https://supabase.com/solutions/ai-builders

[3] Supabase：Create a Supabase backend using Figma Make https://supabase.com/blog/figma-make-support-for-supabase

[4] TechTimes：Open-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] Neon：Looking at How Replit Agent Handles Databases https://neon.com/blog/looking-at-how-replit-agent-handles-databases

[6] Neon：Replit 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] InfoWorld：Databricks 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 Notes：Native Vector Data Type https://dev.mysql.com/doc/relnotes/mysql/9.0/en/

[17] Open Source Initiative：SSPL 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 Notes：file_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