# Perplexity Built Its Own Database with AI Agents. Should You Build More Software Too? > Perplexity says two engineers and hundreds of AI agents built a DynamoDB replacement in two months. The useful lesson is not to copy it, but to rethink build versus buy without forgetting operations. Source: https://mcdougall-digital.de/en/blog/cobbledb-build-vs-buy/ Published: 2026-09-16 Author: Kyluke McDougall, McDougall Digital Language: en --- Perplexity has published one of the most provocative AI software stories of the year. The company says two engineers, working with hundreds of persistent AI agents, built the core of CobbleDB in two months. CobbleDB is a key-value store designed around Perplexity's own web-search workload and intended to replace Amazon DynamoDB for that path. Perplexity also reports workload-specific gains, including roughly five-times lower batch-read latency. Those are company claims, not independently audited results. Even so, the case deserves attention. The wrong lesson is obvious: “AI can build a database, so we should replace our SaaS and cloud services too.” The useful lesson is more demanding: **When AI reduces implementation cost, build versus buy changes—but architecture and operational responsibility do not disappear.** For founders, CTOs, product owners and mid-sized German companies, this distinction matters. AI agents can make custom software viable where it previously looked too expensive. They can also make it easier to create infrastructure that the organisation never needed and is not prepared to operate. ## This was not a generic “build it ourselves” decision Perplexity did not announce a database because databases are interesting. It described a narrow, high-volume workload with measurable pain. The company controls the request pattern, can optimise for it and operates at a scale where latency and cloud cost compound. That creates a plausible case for specialised infrastructure. The sequence matters: 1. A production workload already existed. 2. Its behaviour and costs were observable. 3. The team could isolate a constrained technical seam. 4. A specialised implementation had measurable targets. 5. The expected gain was large enough to justify ownership. That is different from building a custom component because an agent made the first version look easy. Most companies should still buy commodity capabilities. Authentication, payments, email delivery, object storage, observability and databases are usually safer and cheaper as managed services, especially while requirements are ordinary and scale is moderate. Custom software becomes attractive when a generic product imposes a material constraint on something that differentiates the business. ## AI changes one part of the equation A traditional build-versus-buy calculation includes implementation cost, licence or usage cost, integration effort, opportunity cost, maintenance and operational risk. AI agents can reduce implementation effort. They can explore alternatives, generate experiments, write repetitive code, create tests, investigate failures and work across parallel tasks. That can move the point at which a custom solution becomes economically credible. But implementation was never the whole equation. A component that takes two months to create may remain in production for ten years. Somebody must understand it, upgrade it, secure it, monitor it, recover it, document it and decide how it evolves. The new calculation is not: > Can an agent build this? It is: > Does cheaper implementation justify the ownership we are creating? That is a product and architecture decision, not a prompt-engineering decision. ## Generated code is not the scarce resource “Two engineers and hundreds of agents” sounds like an extreme productivity ratio. Yet the scarce human work was probably not typing database code. It was defining the workload, selecting the architecture, decomposing tasks, validating behaviour, resolving contradictions, reviewing risk and deciding whether the result was ready for production traffic. Hundreds of agents create coordination problems as well as output. Parallel changes can conflict. Tests can validate the wrong assumptions. Local improvements can damage system-level properties. Plausible implementations can disagree on invariants. For serious infrastructure, human judgement remains concentrated around questions such as: - What consistency guarantees does the product need? - Which failure modes are acceptable? - How will data be migrated, verified and rolled back? - What happens during partial network or service failure? - Which metrics prove an improvement rather than a faster benchmark? - Who can stop the rollout? - Who owns the system after the launch team moves on? AI can multiply implementation capacity. It also increases the amount of work arriving for review. Architecture, verification and operational design become bottlenecks precisely because code becomes cheaper. ## A practical build-versus-buy test Before commissioning a custom replacement for an existing service, answer five questions. ### 1. Is the workload differentiating? Build when the component affects a capability customers value or a constraint that materially shapes the business. If the requirement is ordinary, a mature managed service usually has better economics. Your team gains little by owning another scheduler, identity provider or message queue merely because it can generate one quickly. ### 2. Is the pain measured? “The bill feels high” and “the service seems slow” are weak foundations. Measure latency distributions, error rates, throughput, unit cost, incidents, engineering time and business impact. Compare a replacement against realistic alternatives, including tuning, caching, a different service tier or another vendor. ### 3. Can the boundary be isolated? A good candidate has a clear interface and a migration path. The team should be able to introduce the component behind an abstraction, mirror traffic, compare results and revert without rewriting the whole product. If replacement requires a big-bang migration, apparent AI speed can hide enormous business risk. ### 4. Can you operate it at 03:00? The build budget is not the operating model. Custom infrastructure needs observability, backups, capacity planning, incident response, security ownership, upgrade paths, disaster recovery and documentation. If only the original builders can diagnose it, the company created a staffing dependency rather than an asset. ### 5. What makes you stop? Define exit criteria before implementation starts. Stop if gains disappear under realistic load, migration risk exceeds the benefit, operational effort is too high, the managed alternative improves, or the expected saving does not survive total-cost analysis. AI makes it cheap to continue producing code. That makes explicit stop conditions more important. ## Start with a bounded challenge The safest way to test whether AI changes your build-versus-buy decision is not to replace a critical platform immediately. Choose one expensive or constraining seam. Build a representative prototype against real workload traces and acceptance criteria. Run it alongside the existing system. Measure correctness, latency, cost and operational burden. Include failure tests and rollback exercises, not only happy-path benchmarks. For a business application, the seam might be a complex pricing calculation, document-processing pipeline, planning engine, legacy integration or reporting workload. These are often better candidates than commodity infrastructure because they carry business-specific knowledge. The objective is not to prove that agents can produce a lot of code. It is to learn whether custom software improves the economics or capability of the product. ## What mid-sized German companies should take from the story Most German companies do not operate Perplexity's search workload. They should not copy Perplexity's infrastructure choices. They can copy the decision discipline: - Optimise around a real workload, not a fashionable technology. - Keep the problem narrow enough to measure. - Treat reported AI speed as an input, not as the business case. - Design migration, observability and rollback before cutover. - Measure total ownership cost, including review and operations. - Keep human accountability for architecture and release decisions. AI-supported development can make bespoke systems more accessible. That is valuable for companies whose processes do not fit standard software or whose competitive advantage lives in a specialised workflow. But custom code is still an asset with a liability attached. Every line must eventually be understood, operated or retired. The CobbleDB story does not mean every team should build more. It means teams can reconsider what is worth building—provided they remain honest about everything that comes after the code is written. That is where architecture-first delivery earns its keep. --- This article was created with the help of AI. McDougall Digital is responsible for its content.