Perplexity built CobbleDB to make AI search faster

Perplexity’s CobbleDB is a specialized distributed key-value store built to serve prepared web-page passages and vector embeddings during AI-search queries. In a technical account published on September 14, 2026, Perplexity reported that moving this part of its search-serving architecture away from Amazon DynamoDB reduced median batch-read latency from 31.4 ms to 5.60 ms.

The result is a database tuned for one job—not a universal replacement for every storage system Perplexity uses. Its design gives the company direct control over partitioning, caching, routing and replicas, while accepting a workload-specific consistency model and the responsibility of operating custom infrastructure.

Perplexity built CobbleDB for one demanding search workload

CobbleDB stores hashed page identifiers as keys. The associated values contain passages that have already been split into chunks, along with vector embeddings for each chunk. That preparation matters: when a search request arrives, the serving layer can retrieve many ready-to-use records instead of handling document processing and hot-path reads as one large operation.

Perplexity describes the system as a hot store for repeated batch reads. Cached records are served from memory; uncached records come from local NVMe storage through RocksDB, the embedded key-value engine used on CobbleDB’s data nodes.

The database handles selected production search traffic. Its role is narrower than a company-wide migration from DynamoDB, and the reported results apply to this particular serving path.

The reported latency gains are large—but not a controlled head-to-head test

Perplexity measured the DynamoDB period before the migration and the CobbleDB period afterward. At roughly 200,000 requests per second, the company reported these batch-read figures:

The median result represents an approximately 82.2% reduction, calculated from the supplied values. Perplexity also reported a later load test reaching up to 500,000 requests per second before performance began to decline. That load-test figure is a separate stress result, not the production traffic level used for the latency measurements.

Perplexity’s internal cost model estimated at least 20% lower storage-layer cost than DynamoDB across the evaluated commitment tiers. That estimate covered the modelled storage, read and write capacity, but excluded the engineering and maintenance costs of running a custom datastore.

How Pillar, Lorry and CobbleDB divide the work

CobbleDB is one part of a three-layer design:

Pillar decides which policy-defined page subsets are exported. Lorry reads those records from a persistent partition-aligned queue, creates per-partition batch files and registers them with CobbleDB. Replicas then retrieve and apply the batches independently in chronological order, allowing a recovering replica to catch up without stopping the rest of the system.

At query time, a stateless router hashes page keys to partitions, groups the reads and sends them to data nodes in parallel. Each partition has three replicas on three different nodes. Routing prefers a replica in the same availability zone when possible, while a slow read can be sent to another replica.

Hundreds of coding agents helped; humans kept production control

CobbleDB’s core database contains approximately 40,000 lines of Rust. Perplexity says two human engineers built it with assistance from hundreds of persistent coding agents over roughly two months.

The agents helped with code inspection, testing, fixes, documentation and project follow-through. Human engineers set the architecture, reviewed consequential changes and authorized production operations. So the interesting story is not that an AI swarm independently launched a database; it is that a small human team used a large number of coding agents to accelerate the surrounding engineering work while retaining control over the decisions that affected production.

The trade-off behind the speed and projected savings

CobbleDB does not require transactions or synchronized replicas for the described hot-store workload. Perplexity accepts a short delay between a document write and the point when that update becomes available for reads.

That trade-off fits prepared search records, where the serving layer repeatedly reads data produced by an asynchronous pipeline. It would not automatically fit workloads that depend on strong consistency, complex transactions or the broader feature set of a managed general-purpose database.

The architecture also shifts responsibility toward Perplexity. It controls partition placement, cache allocation, request routing, replica selection and ingestion, but it must maintain the datastore and its production infrastructure itself. The projected storage savings therefore describe one internal cost model, not the full economic cost of owning the system.

What Perplexity says comes next

Perplexity says it plans to open-source CobbleDB so other teams building AI-native search systems can use the storage layer. The project’s current design remains tightly tied to the prepared-record serving workload that motivated it: fast, repeated reads at search-query time, rather than general-purpose database operations.