Perplexity rewrites AI search storage layer with CobbleDB

The ~40k-line Rust system was built by 2 engineers and hundreds of AI coding agents in two months.Traditional search stacks designed for human readers differ from AI search for language models, which require offline processing of web pages into semantic segments and vector embeddings before querying.

This creates two opposing loads: write-side (offline, large batches, not time-sensitive) and read-side (online, small batches, high latency sensitivity).

The new design separates these loads to avoid interference between backfilling and online reads, addressing DynamoDB's cost per byte, lack of tunability, and inability to optimize for their specific narrow operations.

CobbleDB 深度解读：Perplexity 为什么重写 AI 搜索的存储层 @perplexity_ai 用「一个热存储（CobbleDB）+ 一个持久状态层（Pillar）+ 一个批量投递层（Lorry）」的三件套替换了 DynamoDB，把批量读延迟降低约 5 倍、成本降低至少 20%，而这套约 4 万行 Rust 的系统由 2 名工程师 + 数百个 AI Coding Agents 在两个月内建成；这两组数字共同构成了 Perplexity 的核心表达：在 AI agent 时代，“自建” vs “买托管服务”的天平已经变了。 perplexity.ai/hub/blog/cobbl… # 问题：AI 原生搜索对存储提出了什么不同要求？ 传统搜索栈是为「人类读者」设计的：返回一页排序好的链接即可。而 AI 搜索是为「语言模型」服务的：系统必须在离线阶段把每个网页清洗、切成语义连贯的段落、计算每段的向量嵌入，并把段落和向量一起存好；查询时再按相关性批量取出喂给模型。 这带来两种截然不同的负载： · 写侧（离线处理）：网页持续抓取和更新，且只要切换分块方法或嵌入模型，就可能要重处理语料库的大头。写入天然是大批量、可重放、不赶时间的。 · 读侧（在线服务）：一次 Search API 请求要取 100–120 个页面 key，拆成 10–20 个 key 一批、平均单条 50KB 的批量读，而且就在通向最终答案的关键路径上，必须快。 这两种负载的正确设计方向几乎相反：处理侧要 durable 队列、可重试、可大规模回填；服务侧要预计算好的记录、热缓存、极简的查询时开销。把它们塞进同一个数据库，就会让回填和恢复工作干扰延迟敏感的在线读——这正是 Perplexity 原架构的病根。 # DynamoDB 的三个具体短板 1. 按字节计费的经济性：读写每一个字节都要钱。持续的抓取更新消耗写容量，每次查询取回准备好的页面批次消耗读容量，成本随语料库和流量线性膨胀，且和记录大小、更新频率挂钩，而不仅是调用次数。 2. 无法调优的托管黑盒：Perplexity 需要的操作其实极窄，给一批页面 ID，快速返回准备好的内容。但影响这个操作的所有因素（哪个机器持有哪个分区、多少内存给缓存、哪个副本服务请求）都锁在 DynamoDB 内部。一次缓存未命中、一次跨可用区跳转、一个慢副本，都会拖慢整个批次，而他们无法干预。 3. 处理管道与热存储直连：旧管道把每个处理完的页面直接写入 DynamoDB，于是大规模重处理任务变成对在线库的写入洪峰。他们无法在一两天内对全库跑一遍 MapReduce 来试验新的分块方法或换嵌入模型，这对需要快速迭代模型技术的 AI 搜索公司是致命的速度瓶颈。 # 新架构：职责分离的三件套 CobbleDB ～ 可调优的读路径（热存储） 分布式 KV 存储：key 是页面 ID（哈希后的 URL），value 是预切好的段落和逐段嵌入。要点在于控制权： · 数据分区，每分区 3 副本分布在不同节点；节点用 RocksDB 做本地存储引擎（适合批量喂入、重读取的负载）。 · 热数据走内存，冷数据走本地 NVMe，内存/磁盘配比完全自己调。 · 无状态查询路由器把 key 哈希到分区并行发出请求，优先同可用区副本以避免跨区延迟；某副本响应慢就对冲（hedge）到其他副本，直接改善尾延迟。 · 刻意砍掉不需要的功能：不要事务、不要副本强同步。写入到可读之间有几秒间隙可接受，副本之间摄入进度不一致也可接受。少即是省。 Pillar ～ 持久文档状态与发布决策（基于 YTsaurus） 存储爬取和处理过的一切，把元数据、段落、嵌入分存在不同的 YTsaurus 表族里，并对段落和嵌入做版本化，多套表示共存不互相覆盖，嵌入模型可以随时换。因为 Pillar 走便宜的 HDD，容量远超从前。它还维护「子集」策略，比如新鲜页面、高价值页面，只有子集内的文档才导出到昂贵的 NVMe 热存储。正确性由 YTsaurus 原子事务保证：状态更新、输入确认、导出排队，要么全成要么全不动。 Lorry ～ 批量投递的无状态服务 唯一职责是把 Pillar 的导出记录按分区攒成批次文件。关键设计是数据面与控制面分离：批次写到 S3，只在 CobbleDB 控制面注册；各分区副本各自拉取属于自己的 S3 批次、按序异步应用。慢节点或恢复中的节点按自己的节奏追赶，不会拖累整个系统。 这条链路（Pillar → Lorry → CobbleDB）实现了核心解耦：处理事务与热存储摄入分离，且为增量更新和全量重建提供了可重放的路径。 # 验证结果 指标 ｜ DynamoDB ｜ CobbleDB ｜ 提升 P50 ｜ 31.4 ms ｜ 5.60 ms ｜ ≈5.6× P90 ｜ 56.7 ms ｜ 9.77 ms ｜ ≈5.8× P99 ｜ 123 ms ｜ 24.2 ms ｜ ≈5.1× 生产环境约 200k rps（压测到 500k rps 无退化），每批 10–15 个 key、单条 50KB。值得肯定的是方法论上的诚实：团队明确指出这是观察性的前后对比（两套系统在不同时间服务真实流量，而非同一请求的受控对照），因此又补做了合成基准（10–15 key 批量、100B–100KiB 取值范围）来佐证。 成本上，基于内部的存储量与读写容量估算，每一档承诺折扣下 CobbleDB 都至少便宜 20%，且未计入压缩带来的备份节省，实际可能更高。 # 同样值得注意的：AI agent 集群怎么参与建造 约 4 万行 Rust 的核心库加上周边迁移工作，由 2 名人类工程师 + 数百个持续在线的编码 agent 在两个月内完成。 Agent 集群的特点是跨会话持久（保留项目目标、风险、仓库历史、既往决策），承担了：审计在途工作、代码与基础设施审查、暴露易漏的阻塞项（不安全的恢复假设、过期的构建引用、运行时会失败的配置）、准备修复/测试/监控/文档、跟踪 CI 和评审门禁、监控发布并对照成功准则。 人类仍然掌管架构决策、重要变更评审和生产操作授权，Agent 负责决策之间的持续性检查和跟进。 Perplexity @perplexity_ai We’re publishing research on how we built CobbleDB, our key-value database that serves web content for Perplexity search. Two engineers and a team of hundreds of proactive, always-on AI agents built the core infrastructure in two months. 🔗 View Quoted Tweet

This report is categorized under AITOP's "Models" desk, focusing on US frontier AI labs and Silicon Valley technology leaders. Within our cross-regional analytical framework, it directly maps to AI developer toolchains, coding agents, and engineering workflows and US-China foundation model benchmarks and commercialization comparison. Key entities and technical topics under continuous tracking include Perplexity, CobbleDB, AI search, DynamoDB.

Source attribution: curated from shao__meng (@shao__meng). Cross-source corroboration: 3 independent sources have covered this development (including Perplexity, Aravind Srinivas), confirming industry-wide signal strength.