Perplexity已把Amazon DynamoDB移出供應搜尋產品網頁內容的讀取路徑，改用自家的鍵值儲存系統CobbleDB，規模約4萬行Rust程式碼。根據該公司公開的CobbleDB研究資料，兩名工程師指揮數百個持續運作、不間斷的程式代理，在大約兩個月內完成建置。這些代理沒有任何一個被允許核准正式環境的部署。
重點摘要
- 批次讀取延遲中位數由DynamoDB的31.4毫秒降到CobbleDB的5.60毫秒，改善幅度約82%；第99百分位延遲也從123毫秒降到24.2毫秒。
- 兩名工程師在約兩個月內指揮數百個程式代理，架構決策、程式碼審查與正式環境授權全數留在人手上。
- Perplexity執行長Aravind Srinivas表示，脫離DynamoDB每年最多可為公司省下1億美元；內部推估在大規模運作下，儲存層成本會比DynamoDB低超過20%。
Perplexity為何離開DynamoDB
導火線是價格與掌控權。Perplexity判斷自己在DynamoDB上付出過高，卻仍拿不到想要的讀取效能調校空間。對一個每產出一則回答就得同時取回大量既有文件的產品來說，這個限制相當沉重。
DynamoDB的計價主要看搬動的位元組量，這種模式較貼合交易型的工作負載，卻難以配合回答引擎那種大範圍、以讀取為主的展開模式。Perplexity的論點是，依自家存取形態量身打造的儲存系統，能在成本與效能兩條軸線上同時勝過通用的託管服務。
這套系統怎麼組起來
Perplexity沒有做成單一巨塊，而是把工作拆成三個可各自調校的元件。Pillar負責文件的持久性，並在記錄變動時追蹤版本。Lorry把湧入的更新集結成批次，再送進系統。CobbleDB本身位於服務層，專責查詢當下的低延遲讀取。
底層方面，CobbleDB把實際的資料交易交給RocksDB處理。團隊在這個地基之上疊了可調整的分區與快取策略，目標是在尖峰負載下維持效能。公開數據顯示，改善並非只集中在中位數，而是貫穿整個分布：第90百分位延遲由56.7毫秒降到9.77毫秒。
代理被允許做什麼、不被允許做什麼
業界會爭論的是人力配置這一段。Perplexity形容這次建置是兩名工程師，加上數百個主動、不間斷的AI代理，這些代理跨工作階段提供持續的檢查與後續推進。Srinivas在X上把成果描述為兩名工程師與數百個常駐代理在兩個月內做出的DynamoDB替代品。影響範圍大的決定仍由人保留。
這條界線是刻意劃下的治理設計，而非技術限制。代理負責產出與修改程式碼，工程師則掌管架構、審查進入程式庫的內容，並握有把任何東西推到線上流量前的權限。撰寫基礎設施與營運基礎設施，被當成兩種不同的權限。
與OpenAI的Rust重寫如何對照
這個輪廓看來眼熟。幾天前，OpenAI才說明兩名工程師與Codex把支撐所有ChatGPT資料讀取的服務以Rust重寫。兩家實驗室各自走到同一種模式，也就是極小的人類團隊、龐大的代理群、Rust，以及儲存層的熱路徑，顯示這正在從個案變成一種範本。
Perplexity放棄了什麼
CobbleDB並不是DynamoDB的功能複製品。它不支援強一致性，也不支援複雜交易，而這兩項都是託管服務的預設配備。對於把快取的網頁文件餵給搜尋索引來說，這是划算的取捨；對於需要交易保證的系統而言，則是直接出局的條件。
Perplexity承諾，待系統在每秒數十萬次請求的規模完成正式環境驗證後，就會把CobbleDB開源，但尚未給出釋出日期。在程式碼公開之前，延遲與成本數字都仰賴該公司自行量測的結果。
常見問題
CobbleDB開源了嗎
還沒有。Perplexity表示，等系統在每秒數十萬次請求的規模上於正式環境證明自身之後，就打算把CobbleDB開源，但尚未公布釋出日期。
CobbleDB完全取代了DynamoDB嗎
它取代的是Perplexity搜尋堆疊中供應網頁內容的讀取服務層，而不是DynamoDB的所有用途。CobbleDB缺少強一致性與複雜交易支援，因此需要這些保證的工作負載並不適用。
程式碼中AI代理實際寫了多少
Perplexity沒有公布這約4萬行Rust程式碼的逐行拆解。該公司把兩個月間大部分的實作工作歸功於數百個常駐程式代理，而架構、審查與部署權限則由兩名工程師掌握。
