Perplexity CobbleDB 替代 DynamoDB，宣称每年可节省 1 亿美元
Perplexity 表示，其自研键值数据库 CobbleDB 已在一项关键搜索负载中取代 Amazon DynamoDB，每年最高可节省 1 亿美元。CEO Aravind Srinivas 还称，在数百个持续运行的编程代理协助下，两名工程师仅用两个月就构建了其核心基础设施。
这些说法汇聚了三项格外重大的变化。Perplexity 正将一项重要的托管云负载收归自建。该公司报告称，批量读取延迟大约降低了五倍。它还将 CobbleDB 作为证据，表明小型工程团队如今能够借助 AI 代理构建严肃的基础设施。
这些醒目的数字需要谨慎看待。基准测试和成本估算均由 Perplexity 提供，而两套系统是在不同时间段处理生产流量。该公司尚未公布经独立审计的成本对比、完整的运营成本模型，或数据库的源代码。
尽管如此，CobbleDB 架构展现出一项连贯的技术押注。Perplexity 不再为通用型托管数据库付费，而是围绕一项昂贵且对延迟敏感的操作构建了更专用的系统：为 AI 搜索检索成批的已处理网页。
这使 Amazon DynamoDB 在市场的一个特定角落面临压力。但这并不意味着初创公司应普遍放弃托管数据库。它表明，当一家快速增长的 AI 服务拥有异常可预测的负载、足够的规模，以及用于生成基础设施代码的新工具时，能够实现什么。
Perplexity CobbleDB 瞄准 AI 搜索背后的读取路径
重要的变化并非 Perplexity 又发明了一种数据库，而是该公司围绕为其答案提供数据的精确路径重新设计了存储。
AI 搜索引擎并不只是检索一个页面并展示链接列表。Perplexity 会清理原始 HTML，将页面划分为语义相关的段落，并计算嵌入向量——即用于比较语义的数值表示。随后，它会存储这些段落和嵌入向量，以供后续检索。
当用户提交查询时，Perplexity 首先识别可能相关的页面。其服务系统随后会批量请求这些页面的已处理内容，挑选有用的段落，并将其提供给语言模型。
旧设计将准备好的页面数据存储在 DynamoDB 中。根据 Perplexity 的说法，一个 Search API 请求可能涉及 100 到 120 个页面键。检索过程会将这些键拆分为较小的批次，每批约包含 10 到 20 个页面，平均项目大小接近 50 KB。
这种模式会反复读取相对较大的值。由于答案必须等到相关内容到达后才能继续，它也带来了严苛的延迟要求。一个响应缓慢的副本、一次未命中缓存的读取，或额外的一次网络跳转，都可能拖慢整个批次。
DynamoDB 提供全托管的键值和文档数据库，具备自动扩缩容、复制和运维工具。其托管数据库模型省去了运行分布式存储的大部分工作。这种广泛的服务模式也限制了客户对内部数据放置、缓存、副本选择和存储引擎行为的精细控制。
Perplexity 认为自己需要这些控制能力。CobbleDB 是一个分布式键值热存储系统，也就是说，它保存了查询服务期间必须快速可用的已处理记录。其键是经过哈希处理的页面 URL，值则包含预先切分的段落及相应的向量嵌入。
该公司将这一热存储系统与另外两个系统分离。Pillar 维护持久化文档状态，并决定哪些记录应被发布。Lorry 则将这些导出内容转换为分区批次，交付给 CobbleDB。
这种分工很重要，因为 Perplexity 早期的处理管道会将准备好的页面直接写入 DynamoDB。对分块方法、嵌入模型或记录格式的修改，可能会在同一个服务实时查询的数据库上触发大量单独更新。
在新架构下，处理系统能够保留文档状态，而无需将每项更新都直接送入对延迟敏感的存储层。Lorry 将分区批次放入对象存储，而 CobbleDB 副本则独立且异步地摄取这些批次。
因此，正在恢复的副本可以按自己的节奏处理积压任务。它不必阻塞健康副本，也无需暂停整个集群的数据摄取。Perplexity 还可以重建其已处理语料库的大部分内容，而无需将这项工作直接绑定到在线服务容量。
此次迁移构成了文章的核心张力。DynamoDB 为其客户承担了许多分布式系统职责。Perplexity 认为，其负载足够专用，以至于接受这些通用能力的成本，如今已高于运营一个量身定制替代方案的成本。
为什么 Perplexity 称 CobbleDB 快五倍
CobbleDB 宣称的优势来自于收窄问题范围、控制数据放置，以及移除 Perplexity 读取路径并不需要的保障。
CobbleDB 将数据划分为分布在多个数据节点上的分区。每个分区在三个独立节点上拥有三个副本。如果一个副本不可用，另一个副本仍可继续处理请求。
每个节点使用 RocksDB 存储其分配到的记录。RocksDB 是一款专为本地存储设计的嵌入式键值引擎。高频请求的数据可以保留在内存中，较冷的数据则存储在本地 NVMe 驱动器上。
这种设计让 Perplexity 能够直接控制内存与磁盘之间的平衡。它可以决定哪些机器拥有分区、分配多少内存用于缓存，以及请求如何在副本之间流转。这些控制通常不会在托管服务内部向用户开放。
无状态查询路由器会将每个页面键哈希到对应分区，并并行向相关节点发送请求。路由器会优先选择同一可用区内的副本，以降低跨可用区请求增加网络延迟的可能性。
在每个数据节点内部，CobbleDB 使用 RocksDB 的 MultiGet 操作一次获取多个键。当应用需要从同一本地存储中取得多个值时，RocksDB 接口旨在减少重复工作。
CobbleDB 还采用了对冲读取。如果某个副本响应缓慢，路由器可以向另一副本发起额外请求。系统以消耗一些额外容量为代价，降低单个延迟响应主导完整批次延迟的概率。
根据 Perplexity 的说法，生产环境中的批量读取延迟中位数从使用 DynamoDB 时的 31.4 毫秒降至使用 CobbleDB 时的 5.60 毫秒。第 90 百分位结果则从 56.7 毫秒降至 9.77 毫秒。
报告中的改善也延伸至长尾表现。在第 99 百分位，延迟从 123 毫秒降至 24.2 毫秒。在这三项测量中，宣称的改善幅度介于 5.08 倍至 5.80 倍之间。
Perplexity 表示，这些生产测量涵盖了约 10 到 15 个键的批次，平均项目大小为 50 KB。两套系统的处理量均约为每秒 20 万次请求。该公司还称，已在 CobbleDB 上进行最高每秒 50 万次请求的负载测试，未观察到性能下降。
“快五倍”这一说法需要准确理解。它描述的是特定批量读取负载下的延迟，而非完整的 Perplexity 答案、通用数据库操作，或任意 DynamoDB 应用。
答案生成仍包括查询处理、检索、排序、段落选择、模型推理和网络传输。将存储环节缩短几毫秒可以改善响应速度，尤其是长尾表现，但并不会让整个搜索产品快五倍。
Perplexity 也承认，其生产对比属于观察性比较。DynamoDB 和 CobbleDB 是在不同时间处理实时流量，而非在受控实验中同时接收相同请求。
该公司称，它还补充进行了合成测试，使用包含 10 到 15 个键的批次，以及大小介于 100 字节到 100 KiB 的值。然而，Perplexity 尚未发布足够的基准测试基础设施，供外部人士独立复现完整测试。
这一区别并不会抹去报告中的性能改善。它界定了现有证据所能支持的结论。CobbleDB 看起来针对 Perplexity 的已处理页面读取进行了深度优化，而公开数据尚不足以确立两种数据库之间普遍适用的性能高低。
Perplexity CobbleDB 与 DynamoDB 的较量是一场专用化押注
真正的竞争并不是自建数据库对阵较差的云产品，而是专用化对阵托管服务的运维安全性。
DynamoDB 支持的负载范围远广于 Perplexity 的热存储路径。它提供托管复制、可用性功能、多种一致性选项、备份集成、安全控制，以及无需客户维护底层数据库集群的运营模式。
CobbleDB 则有意省略了一些通用功能。Perplexity 表示，其热存储不需要事务或严格同步的副本。写入与读者可见之间出现短暂延迟可以接受，副本之间暂时不一致也可以接受。
这些让步简化了协调，但也将责任从 AWS 转移给了 Perplexity。
该公司现在必须自行运营分区放置、副本恢复、容量规划、软件升级、硬件选择、可观测性、事故响应和数据恢复。它还必须确保异步摄取不会让服务层出现不可接受的记录版本混合。
当数据是可派生而非不可替代时，这种取舍是合理的。Perplexity 可以从更持久的文档状态中重建准备好的段落和嵌入向量。CobbleDB 看起来并不是客户付款、账户余额或其他事务记录的唯一权威存储位置。
Pillar 承载持久化文档状态，而对象存储保存副本可以重放的批次。CobbleDB 充当该数据的一种可替换、经优化的投影。这与替换一个存储应用唯一规范记录的托管数据库有本质区别。
Perplexity 也得益于规模优势。按用量计费的云服务在负载较小、不确定或快速变化时很有吸引力。它们让团队能够避免大量前期工程与运维投入。
然而，当规模达到一定程度后，持续的读取和写入费用可能超过专用基础设施的成本。只要能够保持新系统的可靠性，拥有稳定访问模式的公司就可以通过掌控更多技术栈来节省资金。
Perplexity 表示，在其内部对比所采用的承诺级别下，CobbleDB 的成本至少比 DynamoDB 低 20%。它还称，这一估算不包括通过压缩可能节省的备份成本。
Srinivas 在其CobbleDB 公告中进一步称，此次迁移每年最多可为 Perplexity 节省 1 亿美元。这一数字尚未得到独立验证。
“至少 20%”与“高达 1 亿美元”之间的差异很重要。前者是技术文章中给出的相对估算，后者则是该公司 CEO 提出的年度上限说法。
Perplexity 尚未公布 DynamoDB 账单、预计的硬件与网络支出，或其计算中包含的人力成本。该公司也未说明，这一上限是否假设未来流量增长、额外工作负载完成迁移、协商后的云服务承诺，或备份方案发生变化。
运行基础设施还会产生一些无法在简单容量比较中体现的成本。工程师必须维护软件、响应故障、测试恢复流程、处理硬件失效，并确保设计能够兼容搜索技术栈其他部分的变化。
与此同时，AWS 无需在 Perplexity 的狭窄基准测试中匹配 CobbleDB 的性能，才能证明 DynamoDB 的价值。其论点在于，客户获得的是托管运营系统，而不只是一个存储引擎。
因此，Perplexity 对 CobbleDB 与 DynamoDB 的比较得出了一个范围有限但有意义的结论：当大型 AI 服务反复读取可预测的衍生数据批次时，专用的本地存储架构可能在经济性上优于通用托管平台。
对于规模较小的公司、事务型数据、不可预测的流量，或缺乏分布式系统专业能力的团队，这一结论的说服力会减弱。在不具备 Perplexity 工作负载的情况下复制其数据库设计，只会复制运维负担，而无法保证获得相应收益。
两名工程师与数百个智能体改变了构建方程
最具影响力的说法或许关乎组织模式：Perplexity 表示，两名工程师和数百个持续运行的编程智能体在两个月内构建了 CobbleDB 的核心。
Srinivas 将该系统描述为用于快速网页内容检索的 DynamoDB 替代方案。他将这一开发速度归因于两名人类工程师与数百个持续运行的“Computer”智能体协作。
Perplexity 的技术说明称，CobbleDB 核心基础设施约包含 40,000 行 Rust 代码。据称，这些智能体持续运行，并承担了项目各环节的实现工作。
这并不意味着数百名自主工程师独立设计了一个生产级数据库。编程智能体集群可以并行生成、测试、审查和修订大量任务，但人类工程师仍然负责定义架构、建立接口、评估失败情况，以及决定哪些内容进入生产环境。
“两名工程师”的表述也可能未涵盖周边贡献。CobbleDB 依赖既有技术和组织系统，包括 RocksDB、对象存储、PostgreSQL 元数据、部署基础设施、监控，以及 Perplexity 已建立的爬取和检索技术栈。
Pillar 和 Lorry 进一步将项目扩展至单一数据库二进制文件之外。迁移需要持久状态管理、批次发布、控制平面协调、副本摄取、查询路由、基准测试和生产验证。
不过，这一开发模式依然值得关注。数据库基础设施传统上需要更大的团队，因为其工作结合了存储引擎、分布式协调、故障恢复、性能测试和持续运营。
当工程师能够将系统拆分为定义明确的组件时，编程智能体可以压缩实现阶段。它们可以产出替代实现、扩大测试覆盖范围、调查错误，并在无需等待人类工作日的情况下处理独立任务。
基础设施可能尤其适合这一模式，因为其大部分行为可以通过机械化方式测试。工程师可以定义延迟目标、正确性属性、重放行为和故障场景，智能体随后便可围绕这些约束迭代。
生产就绪性仍然更难自动化。一个系统即使通过单元测试，也可能因分区不均衡、相关副本丢失、网络拥塞、内存压力、恢复缓慢，或部署与摄取之间罕见的交互而发生故障。
Perplexity 公开的测量结果提供了一些 CobbleDB 经受真实流量考验的证据。但这些数据并未披露其事故历史、恢复时间、值班负担，或区域性服务中断期间的表现。
智能体相关说法也带来了一个测量问题。代码行数和日历耗时无法揭示其中发生了多少人工审查、智能体产出了多少被弃用的实现，或多少既有内部工具为其提供支持。
最清晰的解读是，AI 智能体改变了尝试构建专用数据库的成本。根据 Perplexity 的说法，它们降低了达到生产环境所需的人类实现工作量。
这会影响传统的自建与采购计算。托管服务过去具有显著优势，因为构建分布式替代方案需要一支庞大团队，且节省成本尚未显现。
如果编程智能体降低了初始工程成本，更多高规模公司就能考虑拥有专用的基础设施层。这一变化不会淘汰托管数据库，而是会改变内部专业化在何种节点上变得经济可行。
同样的原则也适用于存储之外。AI 公司可以使用智能体来优化调度器、推理网关、数据管道、评估系统和缓存，以适配云服务必须以更通用方式处理的工作负载。
因此，Perplexity 的结果给市场双方都带来了压力。云服务提供商面对的是软件生产能力成本更低的客户，而工程负责人则必须决定，智能体生成的基础设施会带来持久节省，还是不断扩张的维护负担。
对开发者而言，教训不是因为智能体能生成数据库就去构建一个，而是要保留生成代码周围的推理过程、基准测试、故障测试和运营知识。当软件生产速度超过人类记忆时，可搜索的工程知识库会变得更加重要。
1 亿美元说法存在巨大的验证缺口
Perplexity 已公布了令人信服的工程细节，但其最大的财务和组织层面说法仍属于公司自身主张。
官方技术文章给出了精确的延迟百分位数、批次大小、项目大小、请求速率、副本数量和架构组件。它还坦率地将生产基准描述为迁移前后的观察结果。
这一限定增强了文档的可信度，但并未使该基准成为独立证据。Perplexity 选择了工作负载、运营了两个系统，并报告了结果。
受控比较应在同一时期对两个数据库重放完全相同的请求，并记录等效的持久性、可用性、网络、压缩、缓存和容量假设。
当前比较无法完全将数据库变更与流量构成、缓存温度、部署差异或其他运营条件区分开来。Perplexity 表示其余设置保持不变，但外部人士目前尚无法核验这一说法。
合成基准有助于弥补这一弱点。不过，独立团队仍需要源代码、配置细节、测试数据、客户端行为和基础设施规格，才能复现结果。
成本验证更加困难。Perplexity 表示，其内部模型纳入了存储容量、读取容量单位和写入容量单位。该公司尚未公布底层数量。
完整的比较还应包括计算实例、NVMe 存储、对象存储、网络、备份、控制平面数据库、可观测性、工程人力，以及预期的事故成本。
机会成本同样重要。维护 CobbleDB 的工程师无法将同样的时间投入到提升检索质量、模型路由、用户功能或其他基础设施上。编程智能体减少了部分实现工作，但人类责任仍然存在。
“高达 1 亿美元”的上限尤其值得审视，因为这将代表一笔巨大的基础设施节省。若没有 Perplexity 的基线支出和预测假设，读者无法判断它反映的是当前节省、未来规模、避免的增长成本，还是多项相关迁移。
最稳妥的结论是有限的。Srinivas 宣称年度节省最高可达 1 亿美元，而 Perplexity 的技术团队则报告其内部模型中至少有 20% 的优势。这两个数字都尚未得到独立验证。
可靠性是第二个重大不确定因素。三个副本提供了冗余，但副本数量本身并不能保证可用性。相关故障、软件缺陷、控制平面中断、错误批次和操作失误都可能影响多个副本。
异步摄取带来了另一项权衡。只有当副本间的不一致处于产品容忍范围内时，它才是可接受的。Perplexity 需要监控机制，能够区分无害的延迟与缺失、陈旧或损坏的预处理内容。
对冲读取同样需要谨慎设置限制。发送备用请求可以改善尾部延迟，但过度对冲会恰好在集群已经变慢时增加负载。当路由器能够识别有意义的延迟、又不放大事故时，这一策略才有效。
开源将使若干说法更容易评估。外部工程师可以检查分区管理、恢复逻辑、副本选择、摄取顺序和故障处理。他们还可以测试该设计是否能够迁移至其他 AI 搜索工作负载。
源代码可用性不会揭示 Perplexity 完整的生产成本或可靠性记录，但会推动 CobbleDB 从内部案例研究走向可进行技术测试的项目。
在此之前，最有力的证据支持的是其机制，而非最醒目的标题。专用批量读取、本地 NVMe 存储、受控缓存、具备分区感知能力的路由和宽松一致性，都有可能为这一工作负载降低延迟和成本。
现有证据尚不足以将 CobbleDB 视为 DynamoDB 的通用替代品，也不足以将其报告的节省视为经审计的财务结果。
CobbleDB 迁移后值得关注的事项
三个信号将决定 CobbleDB 会成为重要的基础设施范式，还是仅仅停留在令人印象深刻的内部优化。
第一个信号是承诺中的开源发布。Perplexity 表示计划让 CobbleDB 可用，但尚未提供公开发布日期。
一个包含构建说明、测试、部署工具、基准测试客户端和恢复文档的代码库，将强化该公司的技术论证。缺乏运营指导的代码转储将提供弱得多的证据。
外部测试应聚焦于 Perplexity 所描述的相同工作负载：每批 10 至 15 个页面键、覆盖广泛大小范围的值、热缓存和冷缓存、缓慢副本、节点恢复，以及持续更新摄取。
可复现的延迟结果将强化这样的说法：CobbleDB 的优势来自其架构。若结果明显较弱，则可能表明 Perplexity 的生产环境或工作负载所发挥的作用超过了公开叙述所暗示的程度。
第二个信号是运营历史。CobbleDB 必须在软件升级、流量激增、嵌入迁移、大规模语料库重建、节点故障和可用区问题中持续保持可靠。
Perplexity 最终应披露可用性、恢复时间、副本延迟、事故频率和工程开销。这些测量结果将显示，较低的读取延迟是否伴随着可接受的长期运营成本。
数据库迁移并不会在流量首次切换时就宣告完成。它真正的考验会在数月后到来：最初的建设者不再将全部注意力放在它身上，日常变更开始与恢复路径产生交互。
稳定运行的证据将强化专用型、由智能体构建的基础设施的合理性。即使初始基准测试依然准确，维护需求上升或公开的可靠性问题也会削弱这一论点。
第三个信号是更广泛的采用情况，包括 Perplexity 内部和外部。对内部而言，关键问题在于 CobbleDB 是否仍局限于预先准备好的网页，还是会扩展到其他派生的、读密集型数据集。
对外而言，采用情况将表明其他 AI 搜索团队是否也拥有与 Perplexity 相似的存储模式。企业需要具备类似的批量检索、可重建记录、较宽松的一致性要求，以及足以证明自行运行集群合理性的规模。
云服务提供商可能会作出回应，但未必会复制 CobbleDB。AWS 可能会改进大规模批量读取功能，引入更多针对特定工作负载的控制选项，或让现有替代方案对 AI 检索系统更具吸引力。
更广泛的市场结果不太可能是简单地放弃托管数据库。一种更可能出现的分化正在形成：团队将继续为权威性和不可预测的工作负载保留托管系统，同时为稳定但成本高昂的数据路径构建专用存储。
Perplexity CobbleDB 之所以重要，是因为 AI 智能体似乎正在降低创建这第二类系统的工程门槛。它们让尝试定制基础设施变得更容易，但并不能消除验证性能、理解故障模式以及承担后果的必要性。
开发者和技术采购方应在将该项目视为模板之前，关注其代码发布、独立基准测试和运营记录。如果这些信号支持 Perplexity 的说法，CobbleDB 将不仅仅是一个引人注目的优化案例。它将表明，获得智能体辅助的团队能够重新划定云服务与企业选择自行拥有的软件之间的边界。
