每次对代理型 AI 项目进行架构审查时，都会遇到同样的问题：我们现有的堆栈能否支持即将构建的内容？通过对矢量数据库进行基准测试来回答此问题会很有诱惑力。其中更深层的问题在于：您的架构能否在同一查询中以同样的保证回答有关数据和含义的问题。

而这正是代理实际需具备的功能。这是大多数团队在系统其他部分成型后最后确定的堆栈部分。而操作数据库被视为既定事实。根据《哈佛商业评论》分析服务的数据，仅有 15% 的组织认为其数据基础已为代理型 AI 做好准备。由此会产生一个在白板上看似合理、但在生产环境中开始瓦解的分割式架构。

这两种模式均值得认真比较：

• 统一架构：单个平台会同时处理操作数据和向量搜索。
• 分割式架构：一个专用的向量存储系统（Pinecone、Weaviate 或 Elasticsearch 等搜索引擎）会与运营数据库并行运行，并通过 ETL 管道保持两者之间的同步。

剖析 Postgres 迁移的病毒式传播循环

每隔几个月，一篇熟悉的博客文章就会在开发者生态系统中走红：《Why we moved back to Postgres》（为什么我们回归到 Postgres）。几乎瞬间，评论区就充斥着完全相同的可预见话题：MongoDB 无法扩展，没有联接，事务功能也很薄弱。Tim Carter Clausen 以 The Decipherist 为笔名进行撰写，并在生产环境中运行了十年 MongoDB，从而直接针对每一项批评进行驳斥，同时提供真实的生产数据作为依据。

选择其数据模型与整个堆栈匹配的数据库，可确保您的开发效率不受架构阻力的影响。

深入剖析：SQL 转换开销的成本

典型的 SQL 请求在单次往返中进行八次格式更改：

1. 客户端发送 JSON。
2. 此 API 会将它解析为一个 JavaScript 对象。
3. ORM 工具会将该对象分解为分散在规范化表中的多个行。
4. 数据库正常运行。
5. 这些行被重新组合。
6. 它们被映射回一个对象。
7. 此对象被序列化回 JSON。
8. 响应已发送。

MongoDB 等效于四次转换，而 Clausen 认为称其为四次转换有些夸大其词，因为此数据的形态其实从未改变。SQL 路径中的每次格式变更都会消耗 CPU 和内存、引入延迟，并为缺陷的隐藏提供空间。

架构更新的实情

重命名字段、添加嵌套对象或重组文档均可在 MongoDB 中实时进行，而不出现停机时间。对大型关系表执行相同的操作可能会将写入锁定几分钟甚至几小时。对于每周交付产品的团队来说，此差异并非理论存在。它是今天下午添加字段与安排下一季度维护窗口之间的差异。

索引层的潜在开销

索引层上也出现了同样的架构差异。以一个对任何运行运营系统的人员来说都很熟悉的查询为例：返回某个国家/地区内某款产品的最近 10 笔订单。

• 在文档模型中：单个复合索引会直接提供此服务，包括嵌套在数组内的字段。
• 在关系系统 (JSONB) 中：此等效项通常需为数组内容创建一个 GIN 索引、为标量字段创建一个单独的 B-tree 索引，以及查询计划程序无法避免的一个深度排序。该计划读取的行数超过所需量，且随着数据量的增长，扩展效果并不理想。它们在应用程序层均不可见，但却会反映在您的云账单上。

数据局部性的结构化功能

隐藏在这两点背后的结构性见解是数据局部性。在文档模型中，逻辑模型和物理模型是相同的。应用程序写入的形态与数据库存储的实际形态相同，而数据库存储的形态是检索层返回给 AI 代理的实际形态。此等效性完全消除了碎片化架构所需的同步管道、双写入逻辑和复杂的协调作业。否则，碎片化架构需要使用这些对象才能获得近似相同的结果。

建筑师的决策框架

Pachot 的决策框架着眼于以下技术现实：

• 选择关系型数据库 (Postgres)：适用于为众多不同应用程序提供服务的集中式数据库，而最终的使用案例尚未完全明确。
• 选择文档型数据库 (MongoDB)：适用于基于域模型而构建的单一应用程序，且数据持久化方式与应用程序的推理过程完全一致。

接下来值得一问的问题在于：哪一项描述了您在 2026 年正在构建的工作：具有限界上下文的微服务、每周迭代的架构，还是以应用程序自然思考的方式进行持久化的域对象？

“如果使用正确，数据库则能做到又快又好；而其中最重要的是选择您了解的数据库，或是您想学习的数据库。”
— Franck Pachot，AWS 数据精英兼 Oracle 认证大师

观看讲座