AI
Perplexity built a homemade database with AI agents—but kept humans in control
The search startup deployed hundreds of coding agents to construct CobbleDB, a custom key-value store that slashed latency and costs while keeping engineers firmly in charge of production.
The New Stack
Perplexity faced a familiar cloud dilemma: AWS DynamoDB was too expensive and didn't give the company enough control over read performance. Rather than stick with a managed service, the startup made a bold choice—build its own database. The result is CobbleDB, a roughly 40,000-line Rust key-value store now handling live search traffic and delivering dramatic improvements in speed and cost.
The project itself became a case study in AI-assisted development. Two engineers, aided by hundreds of persistent coding agents, completed the database in just eight weeks. What makes Perplexity's approach noteworthy isn't just that AI helped accelerate the build, but how the company drew a hard line around agent autonomy: the systems that built CobbleDB never actually ran it.
Performance gains and cost savings#
The move from DynamoDB to CobbleDB brought substantial improvements. At median latency, Perplexity measured batch reads at 5.6 milliseconds—a dramatic drop from the 31.4 ms it saw on DynamoDB. Even more impressive were the tail latencies: the p99 marker fell from 123 ms to 24.2 ms. The shift also promises to cut infrastructure costs by at least 20% compared with DynamoDB's pricing across various commitment tiers.
Under load testing, CobbleDB handled 500,000 requests per second before performance degradation became apparent. One important caveat: the latency comparison comes from different measurement periods rather than a side-by-side test with identical traffic patterns.
Why Perplexity needed its own database#
Every search query requires the system to retrieve pre-chunked passages and vector embeddings—typically 100 to 120 page keys per API call, arriving in batches of 10 to 20, with each item averaging around 50 KB. DynamoDB's inflexibility around read handling meant a slow replica could bottleneck the entire operation. The service's pricing model also made scaling difficult as search volume and the document corpus grew.
To solve this, Perplexity separated long-term document storage from the live search layer. The storage architecture splits across three tiers: Pillar maintains durable document state on HDDs, Lorry packages updates into batches and routes them through S3, and CobbleDB serves the live search layer with three replicas per partition. RocksDB keeps frequently accessed data in memory while the rest remains on local NVMe, and the router can quickly switch to another replica if one runs slow—avoiding the bottleneck that plagued DynamoDB.
