Postgres扛不住，DuckDB崩了，Braintrust两年自建了一个AI专用数据库Brainstore

Braintrust 的创始人 Ankur Goyal 写了一篇技术长文，开头一句话就很直白：AI 可观测性，本质上是一个数据库问题。听起来像废话？但他用了将近两年的血泪教训来证明这句话的分量。

Braintrust 是一家做 AI 产品可观测性和评估的公司。你可以理解为：帮你监控和调试 AI 智能体的工具。他们发现，现有的数据库——无论是 Postgres、数据仓库还是浏览器端的 DuckDB——全都扛不住 AI 工作负载。于是他们做了一个很大胆的决定：自己造一个数据库。

这个数据库叫 Brainstore。

Ankur Goyal 的原文标题：AI 可观测性是一个数据库问题

01 AI 的数据有多疯

:::

先说个数字让你感受一下。一个生产环境的 AI 系统，每秒可以产生10 万个 span（观测数据单元）。这还只是写入压力。

更要命的是数据体积。传统的应用监控（APM），一条追踪记录可能就几 KB。但 AI 的追踪记录里包含了完整的提示词、模型回复、中间推理步骤、工具调用，甚至整段对话历史。一个普通的 span 大约 50KB，一条完整的追踪记录大约 10MB。到了 P90 分位，一个 span 可以达到几十 MB，一条追踪记录可以达到几十 GB。

比传统可观测性大了两到三个数量级。这不是渐进式的增长，是质变。

我自己在使用 AI 可观测性工具的时候也有过类似体感。你随便跑一个复杂一点的智能体工作流，产生的日志量就已经远超传统 Web 应用。一次多步骤的工具调用链，里面包含完整的提示词模板、few-shot 示例、函数定义、返回结果、中间状态……光是文本量就足以撑满一个小型数据库。而这还只是一个用户的一次请求。

还有两个更棘手的问题。第一，AI 智能体的追踪可以持续运行几天（不是几秒钟），而且反馈数据会乱序到达。你的数据库必须支持对已完成的追踪记录进行更新。第二，数据是半结构化的——大量超过 1MB 的字段，里面装的本质上是序列化的应用状态。团队记录的不是「调试一个请求需要的最少信息」，而是「复现一个故障或评估一个智能体需要的所有信息」。

这就好比——传统数据库设计来管理一个图书馆的卡片目录，现在你要求它管理一整个城市的监控录像。量级完全不同，存储方式也必须完全不同。

02 双向夹击

:::

读取端的压力同样巨大，而且是双模式的——工程师的使用方式在两个极端之间跳跃。

有时候他们在排查一个具体问题——「给我看这条追踪记录的全部细节」。这条记录可能有几个 GB，加载必须快。有时候他们在做大规模分析——「过去 24 小时内所有失败的评估结果，按错误类型分组」。这需要快速扫描和聚合。

两种模式对数据库的要求完全相反：一个需要精准定位单条记录并快速加载（行存储擅长的），另一个需要扫描大量数据并快速聚合（列存储擅长的）。你不能只优化一个，必须两个都快。传统的解法是用两套系统分别处理——但这正是 Braintrust 之前踩过的坑。

另外还有几个「不可商量」的要求：追踪数据写入后必须立即可见（不能有几分钟的延迟）；乱序数据必须能正确合并；因为提示词经常包含个人信息（PII），很多团队需要私有化部署——这意味着架构必须简单，不能有复杂的集群依赖。

03 旧架构崩了

:::

在 Brainstore 之前，Braintrust 用的是一个三件套架构：开源数据仓库负责存储和分析，Postgres 负责写入后的快速读取，DuckDB 跑在浏览器端做交互式分析。

这在纸上看起来很合理——分工明确嘛。数据仓库负责海量存储，Postgres 负责快速读写，DuckDB 负责交互式分析。三驾马车，各司其职。

但实际运行中，每一层都在出问题。而且问题不是孤立的——它们互相叠加。

数据仓库能吃下原始数据量，但快速更新很困难。各种查询的变通方案叠在一起，端到端的数据延迟仍然是以分钟计的。

Postgres 一开始表现不错——毕竟它最擅长的就是写入后快速读取。但它不是为这种规模和查询模式设计的。负载上升后，读写都开始变慢。有时候写入需要几分钟，数据库直接无响应——因为 GIN 索引的更新速度跟不上写入速度。

DuckDB 在浏览器里跑分析，听起来很酷，但也变成了瓶颈。正确性问题频繁出现，内存用量可以飙升——一个浏览器标签页吃掉好几 GB 内存来处理几 MB 的数据。

还有一个隐性的产品税。Braintrust 团队想做一套统一的查询语法（叫 BTQL），支持动态类型的表达式比如 scores.Factuality < 0.5。但要把这套语法翻译成三种不同的 SQL 方言（Postgres、数据仓库、DuckDB），维护成本越来越不可持续。

全文搜索性能很差，复杂查询会返回错误结果，动态类型表达式很难同时为 Postgres 和数据仓库可靠编译，整个系统的崩溃方式取决于开发者的硬件配置。

折腾了一年多，团队得出结论：这个架构需要推倒重来。

04 三个设计原则

:::

Brainstore 的架构围绕三个核心原则展开：

第一：所有数据存在对象存储上。不依赖本地磁盘。这提供了几乎无限的存储扩展能力和强一致性，运维也简单得多。很多商业方案声称用了对象存储，但元数据、统计信息、共识状态还是依赖本地磁盘——两边的运维复杂度全继承了。

第二：每个客户的数据独立分区。避免了「所有人共享一张大表」的问题。在数据仓库架构里，全局数据集越大，性能下降越明显。独立分区意味着查询只需要扫描该客户的数据，速度快得多。

第三：半结构化数据是一等公民。数据仓库通常把 JSON 拆成列来处理，对于浅层、稳定的结构可以凑合。但 AI 的数据结构变化快、嵌套深、字段大——这种方式直接崩溃。想象一下，一个 AI 智能体调用了 5 个工具，每个工具返回的数据格式都不一样，中间还嵌套了函数调用的参数和返回值。你怎么把这种东西拍平成关系型的列？答案是：你不应该这么做。Brainstore 把半结构化数据当成原生数据类型来处理，支持直接在嵌套结构上做查询和过滤。

Brainstore 整体架构：WAL → 处理 → 压缩 → 索引，读写完全分离

05 写入路径

:::

每一次写入请求都直接追加到对象存储上的预写日志（WAL），大约一个请求一个文件。不需要协调，不需要锁——唯一的全局协调点是通过 Redis 分配事务 ID。这保证了极高的写入吞吐。

然后后台分两步处理：

处理阶段：把新记录分配到一个 segment（中等大小的、按时间排序的数据块），保证同一条追踪记录的所有 span 落在同一个 segment 里。这是后面快速查看单条追踪记录的关键。

压缩阶段：把处理好的 WAL 条目转换成高效的索引格式——倒排索引、行存储、列存储、向量索引、布隆过滤器。他们最初用的是基于 Tantivy（一个 Rust 写的搜索引擎库）的索引格式，后来扩展到了更多格式。

关键设计决策：索引是异步的、持续的。系统永远在追赶，不断产生越来越优化的读取表示。这有点像 LSM-Tree 的思路——写入先落盘，后台慢慢整理。但 Brainstore 把这个思路推向了更极端的方向：不仅是键值对的整理，而是同时维护倒排索引、列存储、行存储、向量索引、布隆过滤器这五种不同的索引格式。每一种都服务于不同的查询模式。

五种索引格式同时维护。听起来很疯狂？但这正是「AI 数据太大太杂」这个问题逼出来的解法。

06 读取路径

:::

读取端有一条显式的查询管线：解析查询（BTQL 或 SQL）→ 生成语法树 → 字段绑定 → 优化（下推过滤条件、裁剪不需要的字段）→ 规划 Tantivy 查询和聚合操作 → 执行并流式返回结果。

最精妙的部分在于实时读取。查询时，Brainstore 在概念上合并三个数据源：还没处理的 WAL 条目（最新的、还没整理的原始数据）、已处理但还没压缩的条目（已分配到 segment 但还没建好索引的数据）、以及完全索引好的数据（查询效率最高的格式）。三个层次就像一个漏斗——数据从最新但查询最慢的层，逐步流向最老但查询最快的层。

这意味着读取不需要等待压缩完成。数据写入后立即可查。这对于实时调试来说至关重要——你改了一行代码，需要马上知道是修好了还是更糟了，不能等几分钟。

对于延迟最敏感的查询路径（比如「给我看最新的追踪记录」和「按 ID 加载这条记录」），Brainstore 还维护了一个小型的临时实时结构，只包含 ID 和时间戳，需要的时候再按需获取完整数据。

性能基准测试：Brainstore 与旧架构的读写吞吐对比

07 五个产品特性

:::

技术架构再漂亮，开发者感受不到也白搭。那么这些底层设计决策最终转化为了哪些用户可以感知的产品特性？

实时性——追踪记录和更新写入后立即可见，不存在「几分钟延迟」的问题。这对于在线调试的工作流是刚需。

精准读取——加载单条追踪记录经过优化，即使 span 有几十 KB、追踪有几 GB，也不需要做全表扫描。

交互式探索——过滤、分组、聚合在大数据量下仍然保持交互性。查询规划器会尽早下推过滤条件、裁剪不需要的字段。

文本优先调试——对提示词和回复的全文搜索是一等查询路径，而不是事后补上的功能。

运维简单——整个系统只依赖无状态容器 + 对象存储 + Postgres（只做元数据）+ Redis（只做事务 ID 分配）。不需要客户运维数据仓库或管理持久磁盘。这对企业客户来说是个大卖点——很多金融、医疗行业的 AI 团队因为数据合规要求必须私有化部署，如果你的系统需要一个 Kubernetes 集群加三台 Elasticsearch 节点才能跑起来，基本上就劝退了一大半客户。

Brainstore 的查询响应延迟数据

08 为什么不用现成的

:::

「你就不能用 ClickHouse / Elasticsearch / 随便什么现成数据库吗？」这可能是很多读者的第一反应。

Ankur 在文中直接回应了这个问题。他说：

有人认为你永远不应该自己造数据库。这是耗时的、困难的，而且已经有很多开源替代品了。在抽象层面上，这是好建议。但如果数据库架构经常崩溃，Braintrust 作为一个平台就无法提供客户期望的体验。

说白了，他们不是因为技术洁癖才自建数据库，而是因为现有方案真的不行。ClickHouse 擅长分析，但对半结构化大字段的支持不够好，私有化部署的运维成本也高。Elasticsearch 擅长全文搜索，但实时写入后立即一致读取不是它的强项，而且集群运维复杂度很高。每一个现成方案都能满足其中两三个要求，但 AI 可观测性需要同时满足全部——超大 payload、半结构化数据、实时更新、双模式读取、私有化部署。这几个要求的交集，目前还真没有现成产品能覆盖。

当然，自建数据库的风险也很大。Ankur 自己也说了，这是「少量集中的大型技术赌注」。他们花了将近两年时间、投入了核心工程团队的大量精力来构建 Brainstore。如果最终发现现有数据库通过某些配置优化就能满足需求，那这两年就白费了。赌对了，护城河极深——因为竞争对手要复制这个能力也得花同样的时间；赌错了，团队精力全耗在基础设施上，产品反而停滞。

这让我想起一个类比：造火箭发动机 vs 买火箭发动机。SpaceX 选择了自建 Merlin 引擎，付出了巨大的前期成本，但最终获得了成本优势和迭代速度上的碾压。Braintrust 选择自建数据库，逻辑是一样的——当你的核心产品体验直接取决于底层基础设施的性能时，外包就意味着把命运交给别人。

写入与索引延迟的基准对比数据

09 对我们意味着什么

:::

我觉得这篇文章最有价值的不是 Brainstore 本身的技术细节（虽然写得很扎实），而是它揭示的一个更大的趋势：

1. AI 正在重塑基础设施层。不只是应用层在变——数据库、存储、查询引擎这些底层组件也必须为 AI 工作负载重新设计。谁先意识到这一点，谁就有先发优势。

2. 「自建 vs 外购」的决策边界在移动。传统智慧是「不要重复发明轮子」。但当你的场景足够独特，现有轮子根本装不上你的车时，自建就变成了唯一选项。AI 时代的很多基础设施问题都在这个交叉点上。

3. 可观测性 = 可调试性 = 产品质量。对于做 AI 产品的团队来说，你能多快看到你的智能体在干什么、哪里出了问题、哪个提示词版本效果更好——这直接决定了你的迭代速度。而迭代速度就是竞争力。

4. 数据体积只会更大。随着智能体变得越来越复杂——多步骤推理、多工具调用、多轮对话上下文——追踪数据的体积只会继续膨胀。今天一条追踪记录 10MB，明年可能是 100MB。而且随着更多团队开始把 AI 智能体部署到生产环境，写入量也会成倍增长。这个问题不会自己消失，只会越来越尖锐。

我最近经常想一个问题：AI 产品的竞争壁垒到底在哪里？不是模型——大家调的都是同一批 API。不是数据——在合规框架下，数据优势越来越难建立。真正的壁垒，可能恰恰在这些「脏活累活」上：谁的可观测性更好、谁的评估更精准、谁的迭代更快。这些能力的底层，就是数据库。

AI 时代的基础设施之战，已经从「谁的模型更强」延伸到了「谁的工具链更完整」。Brainstore 这样的技术赌注，赌的不只是一个数据库——赌的是 AI 工程化的未来。

◇ ◆ ◇

数据来源：Ankur Goyal (Braintrust CEO), "AI observability is a database problem: how Brainstore works"

文章来自于微信公众号 "深思SenseAI"，作者 "深思SenseAI"