Perplexity's agents built a database, then got locked out

Hundreds of coding agents helped write Perplexity's new database. None of them were allowed near the running copy.

The database is CobbleDB, a roughly 40,000-line key-value store in Rust that two engineers shipped in two months and that now serves part of Perplexity's production search traffic, as Thenewstack reports.

At a glance

• Perplexity moved part of its search serving off DynamoDB onto CobbleDB, a roughly 40,000-line key-value store written in Rust, and expects the swap to cost at least 20% less.
• Median batch-read latency measured 5.6 ms after the cutover against 31.4 ms before it, at around 200,000 requests per second; later load tests reached 500,000 before performance started to slip.
• The two databases never ran side by side on identical traffic, and the projected savings leave out the engineers who now have to keep a custom store alive and fix it when it breaks.

If you have not been following: Perplexity used to write its processed web pages straight into DynamoDB, so a big reprocessing job, a new chunker or a new embedding model, competed with live search for the same table. The fix was to pull long-term document storage apart from the database that answers searches.

One search fetches 100 to 120 page keys

Every search sends the serving layer after pre-chunked passages and vector embeddings. A single Search API call pulls 100 to 120 page keys, sliced into batches of 10 to 20, and each item averages about 50 KB.

DynamoDB is managed, which left Perplexity little control over how reads were handled, so one slow replica could hold up a whole batch. It also charged for the steady flow of large reads and writes that search, crawling and reprocessing generate, which made the cloud bill hard to justify as traffic and the corpus grew. CEO Aravind Srinivas has said that moving to in-house database infrastructure like CobbleDB could save up to a hundred million dollars a year.

Median batch reads fell from 31.4 ms to 5.6 ms

Perplexity was handling roughly 200,000 requests per second when it measured CobbleDB at 5.6 ms for a median batch read, against the 31.4 ms it had recorded on DynamoDB before the cutover. At p99, latency went from 123 ms to 24.2 ms.

In later load testing CobbleDB reached 500,000 requests per second before performance started to decline. Perplexity also ran a separate synthetic benchmark, using batches of 10 to 15 keys with values from 100 bytes up to 100 KiB. Its cost model puts CobbleDB at least 20% below DynamoDB across the commitment options it evaluated.

Pillar holds the documents, Lorry ships the updates

The stack splits into three pieces. Pillar keeps durable document state in YTsaurus on HDDs, including versioned metadata, chunks and embeddings. Lorry packages updates into partition-specific batches and moves them through S3 to CobbleDB.

Inside CobbleDB, processed page data sits on three replicas per partition, keyed by hashed URL, with RocksDB holding often-accessed data in memory and the rest on local NVMe. Reads stay inside the same availability zone where possible, and the router can try a different replica instead of letting a slow one stall the batch.

Updates arrive through S3 and each replica applies them on its own, so a replica can fall behind and catch up without blocking the others.

The agents got context, the engineers kept production

The agents were persistent, carrying context across sessions. They caught problems with restore assumptions and runtime configuration, and worked on fixes and tests. What they did not get was the running system: the two engineers kept the architecture and production in their own hands.

That restraint has a named argument behind it. CMU professor Andy Pavlo argued at Percona Live that databases are the hardest and most important challenge for AI agents, partly because mistakes involving production data can be difficult or impossible to reverse. Per daily.dev, Pavlo also sketches an «agent boosting» technique that could cut database optimization from 12 hours to 15 minutes, with agents handling emergencies and humans keeping the architecture.

Shopify and Ramp built custom coding agents around third-party models. Perplexity kept the cloud underneath and replaced a managed service instead.

The latency comparison is not a controlled test: the DynamoDB numbers were recorded before the cutover and CobbleDB's after, on live traffic at different moments. The 20% cost estimate excludes the engineers who maintain the store and answer the pager, and remio reports that no audited cost comparison, full operating-cost model or source code has been published. Odd, in our view, to attach an open-source promise to «at some point» for a database already carrying production search.

When the code goes public

No date has been given for the open-source release. Perplexity says CobbleDB handles part of its search traffic without putting a number on the share, so the interesting checkpoint is the next one it publishes: production measured near 200,000 requests per second, against load tests that began to degrade at 500,000. The other open question is whether the projected 20% saving survives once the cost of running the thing is counted.