AI 时代数据库选型：PostgreSQL 兼容数据库的扩展挑战

Cockroach Labs 发布的《State of AI Infrastructure 2026》报告显示，83% 的工程负责人认为 AI 驱动的数据增长将在未来 24 个月内使现有数据基础设施出现重大瓶颈，近三分之二的高管承认管理层低估了这一临界点到来的速度。该报告及配套文章由 Cockroach Labs 销售工程高级经理 David Joy 署名，核心主张是：AI 工作负载产生的并发、一致性与扩展模式，会让单节点 PostgreSQL 在生产环境上线数月内就触顶，而非像传统应用那样经过多年渐进增长才暴露问题。

AI 工作负载为何比传统应用更快暴露数据库瓶颈

传统应用的用户行为是可预测的：登录、查询、提交表单、等待响应——动作之间的间隔为基础设施留出缓冲空间。AI 应用，尤其是基于智能体的系统，几乎消除了这些间隔。

据 Joy 介绍，单次智能体请求可能扇出到数十个下游工具调用、API 与数据库查询。当并发智能体会话被放大到数千个，流量画像与传统应用截然不同：上下文过期时跨会话同时触发的缓存雪崩（cache stampede）、下游服务抖动引发的重试风暴（retry storms）、并行子任务汇聚到共享状态时形成的写入热点（write hotspots）。这些模式在单节点数据库的能力边界之外生成。

另一个维度是向量检索。检索增强生成（RAG）、推荐引擎、语义搜索等场景需要把事务型操作与向量相似度查询结合使用，并保证两者之间的强一致性。如果向量检索部署在独立系统中，团队就必须跨两个数据层管理同步、冗余与故障模式——对依赖新鲜上下文的 AI 产品而言，更优的架构是让向量检索与事务数据处在同一个一致性模型下。

单节点 PostgreSQL 对 AI 工作负载的硬性约束

PostgreSQL 仍是大量传统工作负载的合理起点，但其单节点架构会在 AI 场景下更快触顶，主要约束体现在三个方面：

• 连接数上限：单实例 PostgreSQL 能承载的并发连接数有限。每个智能体会话可能产生多个并发查询，连接池只能缓解症状，无法消除架构层面的天花板。
• 写入吞吐：单节点 PostgreSQL 只能纵向扩容（加 CPU 与内存），无法跨节点或跨地域分布写入。当智能体执行记录、状态检查点、向量更新同时汇聚到一台机器时，纵向扩容的空间很快耗尽。
• 跨故障的一致性：AI 智能体需要多种类型的内存——即时一致的工作记忆、可在节点故障后存活的 episodic 记忆、版本化且持久化的语义记忆。单节点数据库没有跨节点的分布式一致性原语，一旦实例宕机，所有依赖该实例的智能体会话同步中断。

业务层面的影响不只是查询变慢。工程师不得不把路线图时间花在管理连接压力、纵向扩容上限与故障转移风险上，产品迭代速度被拖慢；用户感受到的则是 AI 体验不一致、响应延迟甚至宕机。

「先 PostgreSQL、后扩展」的建议在 AI 时代是否仍然成立

Joy 认为，「先 PostgreSQL、后续再扩展」这一默认建议隐含的前提是工作负载会沿渐进的曲线增长，给团队留出观察瓶颈的时间窗口。AI 工作负载并不遵循这条曲线——它在生产环境上线后的头几个月就会突破单节点数据库的能力边界。

Cockroach Labs 的核心论点因此落在选型时机上：在绿地阶段做出的数据库选型，将在未来几年里持续影响团队，是后期不得不付出高昂代价去替换的「架构债」。PostgreSQL 语法兼容与 PostgreSQL 的水平扩展能力并不等价——支持熟悉语法、驱动与工具的数据库，仍可能在规模触顶时被迫迁移。

文章本身是 Cockroach Labs 的厂商内容，部分数据来源为其自有调研，受访者构成与抽样方法未在文中披露，引用时需注意区分厂商观点与行业共识。