Perplexity reports coding agents helped build CobbleDB, its DynamoDB replacement
Perplexity says two engineers and hundreds of persistent coding agents built CobbleDB, an internal key-value database for its search stack. It is optimized for repeated batch reads of prepared page records and is not offered externally.

TL;DR
- CobbleDB replaces DynamoDB on Perplexity's prepared-page read path, while Perplexity's architecture thread assigns durable state to Pillar and partitioned batch delivery to Lorry.
- Production batch-read p50 fell from 31.4 ms to 5.60 ms and p99 from 123 ms to 24.2 ms, according to Perplexity's reported measurements.
- Two human engineers and hundreds of persistent coding agents built the core infrastructure in two months, with Perplexity's account reserving architecture, review, and production authorization for engineers.
- The headline claim of up to $100 million in annual savings is prospective: AravSrinivas's follow-up says that figure is not Perplexity's current spend.
Perplexity's engineering post puts CobbleDB's core at roughly 40,000 lines of Rust. It also describes two deliberate allowances: replicas ingest asynchronously, and a slow read can trigger a hedge to another replica.
CobbleDB read path
CobbleDB stores hashed URLs as keys and prepared page representations, including pre-chunked passages and per-chunk embeddings, as values. After retrieval and ranking select candidate pages, a stateless router hashes their keys to partitions and reads those partitions in parallel.
- Each partition has three replicas on separate nodes.
- The router favors a same-availability-zone replica, then conditionally queries another copy when the first is slow.
- Nodes use RocksDB MultiGet for batched reads, serving cache hits from memory and misses from local NVMe.
That is a narrow optimization target. Perplexity's post says its previous Search API request could involve 100 to 120 page keys, split into batches of 10 to 20 records averaging about 50 KB each.
Pillar and Lorry
The write side is separated from the hot store. Pillar maintains versioned document state and publishing decisions, while Lorry turns Pillar exports into per-partition batches for CobbleDB.
Pillar is backed by YTsaurus, where page metadata, chunks, and embeddings live in separate table families. Its transactions must update durable state, account for consumed input, and queue required exports together, or make no change.
Lorry writes each partition's batch to S3 under a unique identifier, then registers it with a PostgreSQL-backed control plane. Replicas independently poll for the next batch and apply updates in order, allowing a recovering replica to catch up without holding back the others.
Production measurements
Perplexity reported these before-and-after batch-read figures after its migration:
- P50: 31.4 ms to 5.60 ms, a 5.61x reduction.
- P90: 56.7 ms to 9.77 ms, a 5.80x reduction.
- P99: 123 ms to 24.2 ms, a 5.08x reduction.
The company says both systems ran at about 200,000 requests per second, with load tests reaching 500,000 requests per second without degradation. Its production comparison used live traffic at different times rather than matched requests, so it measures hot-store batch latency rather than end-to-end answer latency.
Perplexity also estimates CobbleDB is at least 20% cheaper than DynamoDB across commitment tiers. The estimate combines storage, read-capacity, and write-capacity assumptions, and excludes projected backup savings from compression.
Persistent coding agents
Perplexity says its internal agent system retains project goals, active risks, repository history, and prior decisions across sessions. The agents began by mapping existing project threads, pull requests, owners, system health, and next actions.
The work then included:
- Reviewing code and infrastructure changes.
- Finding unsafe restore assumptions, stale build references, and runtime-breaking configuration.
- Preparing fixes, tests, monitoring changes, and operational documentation.
- Tracking CI, review, and infrastructure gates.
- Monitoring rollouts and backup or restore exercises against their success criteria.
Engineers set the architecture, reviewed consequential changes, and authorized production actions. The agent swarm handled continuous inspection and follow-through between those decisions.
Scope and availability
CobbleDB omits synchronized replicas and transaction guarantees because Perplexity accepts a short delay before a write is readable and allows replicas to ingest at different speeds. It is a hot store for repeated batch reads of prepared page records, not a general-purpose database.
Perplexity says it plans to open-source CobbleDB, but AravSrinivas's reply describes it as internal-only for now because the company's needs are shaped by a web index of half a trillion pages. The agent-driven traffic growth in AravSrinivas's clarification is also why the stated $100 million annual saving is framed as an eventual outcome, rather than current database spend.