Home Made CobbleDB Replaces DynamoDB at Perplexity to Cut Query Latency 5x and Reduce Cloud Storage Perplexity replaced Amazon DynamoDB with CobbleDB, an internally developed Rust distributed key-value store, cutting batch-read latencies fivefold and lowering storage expenses by at least 20 percent. The migration addresses DynamoDB's usage-based pricing at production traffic exceeding 200,000 requests per second and its inability to prevent tail-latency spikes from uncached reads, cross-zone hops, and lagging replicas. Perplexity split storage into Pillar for durable state on YTsaurus, Lorry for batch aggregation via Amazon S3, and CobbleDB for low-latency serving with RocksDB, three replicas per partition, and zone-affine routing with speculative hedged reads. Perplexity has transitioned its core search serving tier away from Amazon DynamoDB to CobbleDB, an internally developed distributed key-value store written in Rust https://www.perplexity.ai/hub/blog/cobbledb?utm source=gemini . The migration addresses severe latency and cost bottlenecks that arose from serving multi-kilobyte document batches to large language models under heavy query volumes. By decoupling durable document storage from hot-tier retrieval, the engineering team achieved a fivefold reduction in batch-read latencies while lowering overall storage expenses by at least twenty percent. Artificial intelligence answer engines impose read patterns distinct from conventional document search. Each query dispatched to Perplexity generates between 100 and 120 target page keys, which the retrieval service splits into parallel batches of 10 to 20 keys. Unlike traditional search engines that return brief metadata snippets, retrieval for language models requires extracting full chunked passages and dense vector embeddings, yielding average record payloads of roughly 50 kilobytes. At production traffic scales exceeding 200,000 requests per second, DynamoDB usage-based pricing became financially unsustainable because AWS meters every byte transferred. Additionally, DynamoDB operates as a black box that conceals internal partition placement, memory caching policies, and replica routing. Engineers could not prevent tail-latency spikes caused by uncached reads, cross-zone networking hops, or lagging replicas. Reprocessing jobs triggered by updated chunking algorithms or newer embedding models also pushed high-volume writes directly into DynamoDB, creating noisy neighbor contention against live user requests. To resolve these constraints, Perplexity split its storage architecture into three specialized systems: Pillar for durable state management, Lorry for batch aggregation, and CobbleDB for low-latency serving. Image Source: Generated with Gemini based on details from the article. Pillar runs on YTsaurus over high-capacity mechanical drives, maintaining versioned table families for web page metadata, passages, and vector representations. Atomic YTsaurus transactions guarantee that crawl updates, state mutations, and export queues commit together. Lorry acts as a stateless queue consumer that groups Pillar exports into partition-aligned batch files, storing the payloads in Amazon S3 while posting metadata notices to CobbleDB. CobbleDB worker nodes pull and ingest these S3 batches independently, entirely isolating hot serving nodes from the write-heavy crawl pipeline. CobbleDB operates as a distributed key-value store optimized exclusively for batched lookups. Each partition maintains three replicas distributed across independent compute nodes. The core daemon uses RocksDB as its embedded storage engine, pairing memory-mapped caching with local NVMe solid-state disks. A stateless query router maps hashed page identifiers to partitions and coordinates read execution. To minimize network overhead, the router routes requests to node replicas located within the same availability zone. If a target replica exhibits elevated response times, the router speculatively hedges the request by issuing a concurrent read to an alternate replica on a different node. Within each node, CobbleDB retrieves keys simultaneously through the RocksDB batched MultiGet interface, eliminating round-trip overhead. pub struct BatchedPageRequest { pub keys: Vec