换掉的不是一个数据库

Perplexity 官方博客的说法是：托管数据库给了可靠的存储，但他们对「数据怎么存、读怎么服务」控制有限，而且按量计费会随索引规模与查询量一起涨；更麻烦的是旧管线把文档处理直接绑在服务库的写入上，导致想换一种切分方式、换一个 embedding 模型、或者加一个字段，都要面对一波直接的写压力。重构因此不只是换库：他们把文档持久状态与发布交给 Pillar，把批量更新交给 Lorry，查询时读的才是 CobbleDB 这个键值热存储。

官方给出的数字

生产前后对比：批量读延迟整体约降 5 倍，P50 从 31.4ms 降到 5.60ms，P90 从 56.7ms 降到 9.77ms，P99 从 123ms 降到 24.2ms。成本上，官方按内部对存储量、写容量单位与读容量单位的估算，认为在每个承诺档位上 CobbleDB 至少比 DynamoDB 便宜 20%，并提到若计入压缩带来的备份节省，真实差距可能更大。Perplexity 特别声明 CobbleDB 不是通用数据库，而是为「反复批量读取预处理页面记录」这个特定负载做的专用件。

哪个数字可信到哪一步

延迟是生产实测，可信度较高；20% 的成本下降是内部模型估算，官方也承认没有把备份节省算进去；而社交媒体上流传的「每年最多省一亿美元」来自 CEO 的表述，与博客里的口径并不一致。做技术决策时把这三个层次分开看，比记住一个最大的数字更有用。

真正让实验跑得动的是分层：持久状态、更新投递、查询服务分开以后，重跑一次全量清洗才不会撞上线上读。