Perplexity CobbleDB Replaces DynamoDB, With a Claimed $100 Million Annual Saving

Perplexity says CobbleDB, its custom key-value database, has replaced Amazon DynamoDB in a critical search workload and could save up to $100 million annually. CEO Aravind Srinivas also says two engineers built its core infrastructure in two months, assisted by hundreds of persistent coding agents.

Those claims combine three unusually large stories. Perplexity is bringing a major managed-cloud workload in-house. It reports roughly fivefold lower batch-read latency. It also presents CobbleDB as evidence that small engineering teams can now build serious infrastructure with AI agents.

The headline numbers require caution. Perplexity produced the benchmarks and cost estimates, while the systems handled production traffic during different periods. The company has not published an independently audited cost comparison, a complete operating-cost model, or the database’s source code.

Still, the CobbleDB architecture reveals a coherent technical bet. Perplexity stopped paying for a general-purpose managed database and built a narrower system around one expensive, latency-sensitive operation: retrieving batches of processed web pages for AI search.

That puts Amazon DynamoDB under pressure in a specific corner of the market. It does not show that startups should broadly abandon managed databases. It shows what becomes possible when a fast-growing AI service has an unusually predictable workload, enough scale, and new tools for producing infrastructure code.

Perplexity CobbleDB Targets the Read Path Behind AI Search

The significant change is not that Perplexity invented another database. It is that the company redesigned storage around the exact data path that supplies its answers.

An AI search engine does more than retrieve a page and display a list of links. Perplexity cleans raw HTML, divides pages into semantically related passages, and computes embeddings, which are numerical representations used to compare meaning. It then stores those passages and embeddings for later retrieval.

When someone submits a query, Perplexity first identifies potentially relevant pages. Its serving system then requests the processed contents of those pages in batches, selects useful passages, and supplies them to a language model.

The old design placed prepared page data in DynamoDB. According to Perplexity, a Search API request can involve 100 to 120 page keys. The retrieval process divides those keys into smaller batches containing approximately 10 to 20 pages, with an average item size near 50 KB.

This pattern generates repeated reads of relatively large values. It also creates a difficult latency requirement because the answer cannot proceed until the relevant content arrives. One slow replica, an uncached read, or an extra network hop can hold up the entire batch.

DynamoDB offers a fully managed key-value and document database with automatic scaling, replication, and operational tooling. Its managed database model removes much of the work involved in running distributed storage. That broad service model also limits how closely a customer can control internal placement, caching, replica selection, and storage-engine behavior.

Perplexity concluded that it needed those controls. CobbleDB is a distributed key-value hot store, meaning it holds processed records that must be available quickly during query serving. Its keys are hashed page URLs, while its values contain pre-split passages and the corresponding vector embeddings.

The company separates that hot store from two other systems. Pillar maintains durable document state and decides which records should be published. Lorry converts those exports into partitioned batches for delivery to CobbleDB.

This division matters because Perplexity’s earlier processing pipeline wrote prepared pages directly into DynamoDB. A change to its chunking method, embedding model, or record format could trigger a large wave of individual updates against the same database serving live queries.

Under the new architecture, the processing system can preserve document state without forcing every update directly through the latency-sensitive store. Lorry places partitioned batches in object storage, while CobbleDB replicas ingest those batches independently and asynchronously.

A recovering replica can therefore process its backlog at its own pace. It does not have to block healthy replicas or pause ingestion across the cluster. Perplexity can also rebuild large parts of its processed corpus without tying that work directly to live serving capacity.

The migration creates the article’s central tension. DynamoDB handles many distributed-systems responsibilities for its customers. Perplexity believes its workload is specialized enough that accepting those general capabilities now costs more than operating a purpose-built alternative.

Why Perplexity Says CobbleDB Is Five Times Faster

CobbleDB’s reported advantage comes from narrowing the problem, controlling data placement, and removing guarantees that Perplexity’s read path does not need.

CobbleDB divides data into partitions distributed across multiple data nodes. Every partition has three replicas on three separate nodes. If one copy becomes unavailable, another can continue handling requests.

Each node stores its assigned records with RocksDB, an embedded key-value engine designed for local storage. Frequently requested data can remain in memory, while colder records reside on local NVMe drives.

That design gives Perplexity direct control over the balance between memory and disk. It can decide which machines own partitions, how much memory supports caching, and how requests move among replicas. Those controls are not normally exposed inside a managed service.

A stateless query router hashes each page key to its partition and sends requests to the relevant nodes in parallel. The router prefers a replica in the same availability zone, reducing the chance that a cross-zone request adds network latency.

Inside each data node, CobbleDB uses RocksDB’s MultiGet operation to fetch several keys together. The RocksDB interface is designed to reduce repeated work when an application needs multiple values from the same local store.

CobbleDB also uses hedged reads. If one replica responds slowly, the router can send another request to a different replica. The system spends some additional capacity to reduce the chance that one delayed response controls the latency of a complete batch.

According to Perplexity, median production batch-read latency fell from 31.4 milliseconds with DynamoDB to 5.60 milliseconds with CobbleDB. The 90th-percentile result dropped from 56.7 milliseconds to 9.77 milliseconds.

The reported improvement extended to the tail. At the 99th percentile, latency declined from 123 milliseconds to 24.2 milliseconds. Across those three measurements, the claimed improvement ranged from 5.08 to 5.80 times.

Perplexity says these production measurements covered batches of roughly 10 to 15 keys, with an average item size of 50 KB. Both systems handled about 200,000 requests per second. The company also reports running CobbleDB load tests at up to 500,000 requests per second without observed degradation.

The phrase “five times faster” needs precise interpretation. It describes latency for a particular batch-read workload, not complete Perplexity answers, general database operations, or arbitrary DynamoDB applications.

Answer generation still includes query processing, retrieval, ranking, passage selection, model inference, and network delivery. Removing several milliseconds from storage can improve responsiveness, especially at the tail, but it does not make the entire search product five times faster.

Perplexity also acknowledges that its production comparison was observational. DynamoDB and CobbleDB served live traffic at different times, rather than receiving the same requests simultaneously under a controlled experiment.

The company says it supplemented those measurements with synthetic tests using batches of 10 to 15 keys and values ranging from 100 bytes to 100 KiB. However, Perplexity has not released enough benchmark infrastructure for outsiders to reproduce the complete test independently.

That distinction does not erase the reported improvement. It defines what the evidence supports. CobbleDB appears heavily optimized for Perplexity’s prepared-page reads, while the public data does not establish a universal performance hierarchy between the two databases.

Perplexity CobbleDB vs DynamoDB Is a Specialization Bet

The real contest is not an in-house database against an inferior cloud product. It is specialization against the operational safety of a managed service.

DynamoDB supports workloads far broader than Perplexity’s hot-store path. It provides managed replication, availability features, multiple consistency options, backup integrations, security controls, and an operating model that does not require customers to maintain the underlying database fleet.

CobbleDB deliberately omits some general-purpose features. Perplexity says its hot store does not require transactions or tightly synchronized replicas. A short delay between a write and its visibility to readers is acceptable, as is temporary disagreement between replicas.

Those concessions simplify coordination. They also shift responsibility from AWS to Perplexity.

The company must now operate partition placement, replica recovery, capacity planning, software upgrades, hardware selection, observability, incident response, and data restoration. It must ensure that asynchronous ingestion never leaves the serving layer with an unacceptable mix of record versions.

This is a rational trade when the data is derived rather than irreplaceable. Perplexity can reconstruct prepared passages and embeddings from more durable document state. CobbleDB does not appear to be the sole authoritative home for customer payments, account balances, or other transactional records.

Pillar carries the durable document state, while object storage holds batches that replicas can replay. CobbleDB serves as a replaceable, optimized projection of that data. That is materially different from replacing a managed database that stores an application’s only canonical records.

Perplexity also benefits from scale. Usage-based cloud services are attractive when a workload is small, uncertain, or rapidly changing. They let a team avoid substantial upfront engineering and operating work.

At sufficient volume, however, recurring read and write charges can exceed the cost of dedicated infrastructure. A company with stable access patterns can then save money by owning more of the stack, provided it can keep the new system reliable.

Perplexity says CobbleDB is at least 20 percent cheaper than DynamoDB across the commitment levels used in its internal comparison. It also says that estimate excludes possible backup savings from compression.

Srinivas went further in his CobbleDB announcement, claiming that the migration could save Perplexity as much as $100 million per year. That figure has not been independently verified.

The difference between “at least 20 percent” and “up to $100 million” is important. The first is a relative estimate presented in the technical article. The second is an upper-bound annual claim from the company’s CEO.

Perplexity has not published the DynamoDB bill, the projected hardware and networking expenses, or the labor costs included in its calculation. It has not explained whether the upper bound assumes future traffic, completed migration of additional workloads, negotiated cloud commitments, or backup changes.

Running infrastructure also creates costs that do not appear in a simple capacity comparison. Engineers must maintain the software, respond to incidents, test recovery procedures, manage hardware failures, and keep the design compatible with changes elsewhere in the search stack.

AWS, meanwhile, does not need to match CobbleDB’s performance on Perplexity’s narrow benchmark to defend DynamoDB’s value. Its argument is that customers receive a managed operational system, not only a storage engine.

The Perplexity CobbleDB vs DynamoDB comparison therefore has a limited but meaningful conclusion. When a large AI service repeatedly reads predictable batches of derived data, a specialized local-storage architecture can outperform the economics of a general managed platform.

That conclusion becomes weaker for smaller companies, transactional data, unpredictable traffic, or teams without distributed-systems expertise. Copying the database design without sharing Perplexity’s workload would copy the operational burden without guaranteeing the benefit.

Two Engineers and Hundreds of Agents Changed the Build Equation

The most consequential claim may be organizational: Perplexity says two engineers and hundreds of persistent coding agents built CobbleDB’s core in two months.

Srinivas described the system as a replacement for DynamoDB used in fast web-content retrieval. He attributed the development pace to two human engineers working with hundreds of persistent “Computer” agents.

Perplexity’s technical account says the core CobbleDB infrastructure contains roughly 40,000 lines of Rust. The agents reportedly ran continuously and handled implementation work across the project.

That does not mean hundreds of autonomous engineers independently designed a production database. A coding-agent swarm can generate, test, review, and revise many tasks in parallel, but human engineers still define architecture, establish interfaces, evaluate failures, and decide what enters production.

The two-engineer framing may also exclude surrounding contributions. CobbleDB depends on existing technologies and organizational systems, including RocksDB, object storage, PostgreSQL metadata, deployment infrastructure, monitoring, and Perplexity’s established crawling and retrieval stack.

Pillar and Lorry further expand the project beyond a single database binary. The migration required durable state management, batch publishing, control-plane coordination, replica ingestion, query routing, benchmarking, and production validation.

The reported development model is nevertheless notable. Database infrastructure has traditionally demanded larger teams because its work combines storage engines, distributed coordination, failure recovery, performance testing, and continuous operations.

Coding agents can compress the implementation phase when engineers can decompose the system into well-specified components. They can produce alternative implementations, expand test coverage, investigate errors, and work on independent tasks without waiting for a human workday.

Infrastructure may be particularly suitable for this model because much of its behavior can be tested mechanically. Engineers can define latency targets, correctness properties, replay behavior, and failure scenarios. Agents can then iterate against those constraints.

Production readiness remains harder to automate. A system can pass unit tests and still fail because of uneven partitions, correlated replica loss, network congestion, memory pressure, slow recovery, or a rare interaction between deployment and ingestion.

Perplexity’s public measurements provide some evidence that CobbleDB survived real traffic. They do not disclose its incident history, recovery times, on-call burden, or performance during regional service disruptions.

The agent claim also creates a measurement problem. Lines of code and elapsed calendar time do not reveal how much human review occurred, how many discarded implementations the agents produced, or how much preexisting internal tooling supported them.

The clearest interpretation is that AI agents changed the cost of attempting a specialized database. They reduced the amount of human implementation labor required to reach production, according to Perplexity.

That affects the traditional build-versus-buy calculation. Managed services once held a strong advantage because constructing a distributed alternative demanded a large team before any savings appeared.

If coding agents reduce that initial engineering cost, more high-scale companies can consider owning narrow infrastructure layers. The shift would not eliminate managed databases. It would move the point at which internal specialization becomes economically plausible.

The same principle applies beyond storage. AI companies can use agents to optimize schedulers, inference gateways, data pipelines, evaluation systems, and caches around workloads that cloud services must treat more generally.

Perplexity’s result therefore pressures both sides of the market. Cloud providers face customers with cheaper software-production capacity, while engineering leaders must decide whether agent-generated infrastructure creates durable savings or an expanding maintenance portfolio.

For developers, the lesson is not to build a database because agents can generate one. It is to preserve the reasoning, benchmarks, failure tests, and operating knowledge surrounding generated code. A searchable engineering knowledge base becomes more important when software production moves faster than human memory.

The $100 Million Claim Has a Large Verification Gap

Perplexity has published persuasive engineering details, but its largest financial and organizational claims remain company assertions.

The official technical post gives exact latency percentiles, batch sizes, item sizes, request rates, replica counts, and architectural components. It also openly describes the production benchmark as a before-and-after observation.

That caveat strengthens the document’s credibility, but it does not turn the benchmark into independent evidence. Perplexity selected the workload, operated both systems, and reported the results.

A controlled comparison would replay identical requests against both databases during the same period. It would document equivalent durability, availability, networking, compression, caching, and capacity assumptions.

The current comparison cannot fully separate the database change from traffic composition, cache temperature, deployment differences, or other operational conditions. Perplexity says it held the remaining setup constant, but outsiders cannot inspect that claim yet.

The synthetic benchmark helps address this weakness. However, an independent team would still need source code, configuration details, test data, client behavior, and infrastructure specifications to reproduce it.

Cost verification is even more difficult. Perplexity says its internal model incorporates storage size, read-capacity units, and write-capacity units. The company has not released the underlying quantities.

A complete comparison should also include compute instances, NVMe storage, object storage, networking, backups, control-plane databases, observability, engineering labor, and the expected cost of incidents.

Opportunity cost matters too. Engineers maintaining CobbleDB cannot spend the same time improving retrieval quality, model routing, user features, or other infrastructure. Coding agents reduce some implementation work, but human accountability remains.

The $100 million upper bound deserves particular scrutiny because it would represent an enormous infrastructure saving. Without Perplexity’s baseline expenditure and forecast assumptions, readers cannot determine whether it reflects current savings, future scale, avoided growth, or multiple related migrations.

The safest conclusion is narrow. Srinivas claims annual savings of up to $100 million, while Perplexity’s technical team reports at least a 20 percent advantage in its internal model. Neither figure has received independent validation.

Reliability is the second major uncertainty. Three replicas provide redundancy, but replica count alone does not guarantee availability. Correlated failures, software defects, control-plane outages, bad batches, and operational mistakes can affect multiple copies.

Asynchronous ingestion creates another tradeoff. Replica disagreement is acceptable only while it stays within the product’s tolerance. Perplexity needs monitoring that can distinguish harmless lag from missing, stale, or corrupted prepared content.

Hedged reads also require careful limits. Sending backup requests can improve tail latency, but aggressive hedging increases load precisely when a cluster is already slow. The strategy works when the router can identify meaningful delays without amplifying an incident.

Open sourcing would make several claims easier to evaluate. External engineers could inspect partition management, recovery logic, replica selection, ingestion ordering, and failure handling. They could also test whether the design transfers to other AI search workloads.

Source availability would not reveal Perplexity’s complete production cost or reliability record. It would, however, move CobbleDB from an internal case study toward a technically testable project.

Until that happens, the strongest evidence supports the mechanism rather than the largest headline. Specialized batch reads, local NVMe storage, controlled caching, partition-aware routing, and relaxed consistency can plausibly reduce latency and cost for this workload.

The evidence does not yet support treating CobbleDB as a general replacement for DynamoDB or its reported savings as an audited financial result.

What to Watch After the CobbleDB Migration

Three signals will determine whether CobbleDB becomes an important infrastructure model or remains an impressive internal optimization.

The first is the promised open-source release. Perplexity says it plans to make CobbleDB available, but it has not provided a public release date.

A repository with build instructions, tests, deployment tooling, benchmark clients, and recovery documentation would strengthen the company’s technical case. A code dump without operational guidance would offer much weaker evidence.

External testing should focus on the same workloads Perplexity describes: batches of 10 to 15 page keys, values across a wide size range, warm and cold caches, slow replicas, node recovery, and sustained update ingestion.

Reproducible latency results would reinforce the claim that CobbleDB’s advantage comes from its architecture. Materially weaker results would suggest that Perplexity’s production environment or workload contributes more than the public narrative implies.

The second signal is operating history. CobbleDB has to remain reliable through software upgrades, traffic spikes, embedding migrations, large corpus rebuilds, failed nodes, and availability-zone problems.

Perplexity should eventually disclose availability, recovery time, replica lag, incident frequency, and engineering overhead. Those measurements would show whether lower read latency came with an acceptable long-term operational cost.

A database migration is not finished when traffic first moves. Its real test arrives months later, when the original builders are no longer focused exclusively on it and routine changes begin interacting with recovery paths.

Evidence of stable operation would strengthen the case for specialized, agent-built infrastructure. Rising maintenance requirements or public reliability problems would weaken it, even if the initial benchmark remains accurate.

The third signal is broader adoption, inside and outside Perplexity. Internally, the key question is whether CobbleDB stays confined to prepared web pages or expands to other derived, read-heavy datasets.

Externally, adoption would show whether other AI search teams share Perplexity’s storage pattern. Companies would need similar batched retrieval, reconstructable records, relaxed consistency requirements, and enough scale to justify running their own cluster.

Cloud providers may respond without copying CobbleDB. AWS could improve features for large batch reads, introduce more workload-specific controls, or make existing alternatives more attractive for AI retrieval systems.

The broader market outcome is unlikely to be a simple retreat from managed databases. A more probable split is emerging. Teams will retain managed systems for authoritative and unpredictable workloads while building specialized stores for stable, expensive data paths.

Perplexity CobbleDB matters because AI agents appear to reduce the engineering threshold for creating that second category. They make custom infrastructure easier to attempt, but they do not remove the need to verify performance, understand failure modes, or own the consequences.

Developers and technology buyers should follow the code release, independent benchmarks, and operating record before treating the project as a template. If those signals support Perplexity’s claims, CobbleDB will become more than a striking optimization story. It will show that agent-assisted teams can redraw the boundary between cloud services and software a company chooses to own.