Perplexity built a Rust database to replace DynamoDB reads, and cut median batch-read latency from 31.4 ms to 5.6 ms

Amanda Caswell reports at The New Stack that Perplexity has replaced part of its DynamoDB read path with a custom key-value store called CobbleDB, written in Rust by two engineers over two months, with hundreds of coding agents helping through the build. The New Stack puts CobbleDB at 40,000 lines of Rust and says it now handles part of Perplexity's production search traffic.

The numbers Perplexity reports

According to The New Stack, Perplexity measured median batch-read latency at 5.6 milliseconds on CobbleDB, compared with 31.4 milliseconds on DynamoDB before the cutover. At the 99th percentile, latency fell from 123 milliseconds to 24.2 milliseconds. The workload during those measurements was in the region of 200,000 requests per second. In later load testing, The New Stack writes, CobbleDB reached 500,000 requests per second before performance started to drop.

The comparison is not a controlled side-by-side test. The New Stack says the DynamoDB numbers were recorded before the switch and CobbleDB's afterward, and that Perplexity separately ran synthetic benchmarks using batches of 10 to 15 keys with values from 100 bytes to 100 KiB. Perplexity's own cost estimate, as reported, puts CobbleDB at least 20 percent below DynamoDB across the commitment options it evaluated, and does not include the cost of engineers to maintain the new store.

How the storage is laid out

The New Stack describes a three-tier stack. A component called Pillar keeps long-term document state in YTsaurus on HDDs, including versioned metadata, chunks and embeddings. Lorry packages updates into partition-specific batches and moves them through S3 into CobbleDB. Each search request pulls 100 to 120 page keys in batches of 10 to 20, with items averaging 50 KB, The New Stack writes.

Processed page data is spread across three replicas per partition, keyed by hashed URLs, with RocksDB holding hot data in memory and colder data on local NVMe. Reads stay in the same availability zone where possible, and the router can move on to another replica if one is slow rather than hold the whole batch on the slowest response.

Where the humans stayed in control

CMU database researcher Andy Pavlo has argued that databases are one of the hardest and highest-risk targets for AI coding agents, because mistakes on production data can be hard or impossible to reverse. Perplexity's answer, as The New Stack tells it, was to let hundreds of agents help write CobbleDB but keep them out of the running system. The two engineers owned the architecture and production deployment, and the agents carried context across sessions on fixes, tests, and restore assumptions rather than operating the database.

Perplexity says it expects to open-source CobbleDB at some point, though The New Stack does not give a date for that.

The pattern here for a working team is the split of duties. AI-assisted development let a two-engineer team ship a custom store that would once have needed a much larger group, and the risky operations, the production data path and the on-call, stayed with named humans. That split is worth borrowing for any team thinking about replacing a managed service with something it owns.

Source

• Amanda Caswell, Perplexity's AI agents helped build a database. They weren't allowed to run it., The New Stack, 16 September 2026.