Perplexity heeft op 14 september 2026 CobbleDB beschreven: een gedistribueerde key-value-hot store die vooraf verwerkte webpagina’s snel beschikbaar maakt voor AI-zoekopdrachten. In de gemelde productie-vergelijking daalde de mediane batch-leestijd van 31,4 naar 5,60 milliseconden. De p99-latentie ging van 123 naar 24,2 milliseconden.
Die winst komt niet uit een algemene database die elke taak moet kunnen uitvoeren. CobbleDB is juist strak toegesneden op herhaalde batchlezingen van tekstpassages en vectorrepresentaties. Perplexity verving DynamoDB daarmee voor een deel van zijn zoekinfrastructuur, niet voor elke databasebelasting binnen het bedrijf.
Perplexity bouwde CobbleDB voor één veeleisende zoektaak
CobbleDB gebruikt gehashte pagina-identifiers als sleutels. De waarden bevatten vooraf in stukken verdeelde passages en voor elk stuk een vectorrepresentatie. Zo hoeft de zoeklaag tijdens een query niet telkens dezelfde voorbereidende verwerking opnieuw uit te voeren.
Het systeem is geschreven in Rust en de kern omvat ongeveer 40.000 regels code. Perplexity gebruikt RocksDB op de datanodes, bewaart veelgebruikte records in het geheugen en leest niet-gecachete records van lokale NVMe-opslag. Elke partitie heeft drie replica’s op drie verschillende nodes.
Dat ontwerp past bij een zoekdienst die veel vergelijkbare leesverzoeken parallel afhandelt. Het maakt CobbleDB echter niet tot een universele vervanger voor databases met complexe transacties of sterke, overal gesynchroniseerde consistentie.
De gemelde latencywinst is groot, maar komt uit een voor-na-vergelijking
Perplexity rapporteert de volgende productie-uitkomsten voor batchlezingen:
| Maatstaf | DynamoDB vóór de migratie | CobbleDB na de migratie |
| Mediaan | 31,4 ms | 5,60 ms |
| p90 | 56,7 ms | 9,77 ms |
| p99 | 123 ms | 24,2 ms |
De metingen vonden plaats bij ongeveer 200.000 verzoeken per seconde. Perplexity rapporteerde later ook een belastingstest tot 500.000 verzoeken per seconde, voordat de prestaties begonnen af te nemen. Dat is een testresultaat en geen vastgestelde productiebelasting.
De latencycijfers zijn afkomstig uit een observatie vóór en na de overstap: DynamoDB werd in de eerdere periode gemeten en CobbleDB daarna. Het gaat dus niet om identiek live verkeer dat gelijktijdig over beide systemen liep. De cijfers laten wel zien welk verschil Perplexity in zijn eigen productieomgeving rapporteert.
Pillar, Lorry en CobbleDB verdelen het werk
De architectuur splitst duurzame opslag, updateverwerking en snelle uitlevering op in drie lagen:
| Component | Rol in de beschreven architectuur | Relevante technologie |
| Pillar | Beheert versieerbare, duurzame documentstatus met metadata, passages en embeddings | YTsaurus en harde schijven |
| Lorry | Leest exportrecords, maakt batches per partitie en levert die aan CobbleDB | Amazon S3 voor de datastroom |
| CobbleDB | Neemt voorbereide records op en serveert ze tijdens zoekopdrachten | Rust, RocksDB, geheugen en lokale NVMe-opslag |
Pillar bepaalt welke beleidsmatig geselecteerde paginaverzamelingen naar volgende systemen worden geëxporteerd. Lorry zet die records om in partitiegebonden batchbestanden. Replica’s van CobbleDB kunnen die bestanden zelfstandig in chronologische volgorde verwerken, zodat een trage of herstellende replica kan bijwerken zonder de rest van het systeem op te houden.
Tijdens een zoekopdracht hasht een stateless router de pagina-identifiers naar partities. Vervolgens worden de leesverzoeken parallel naar datanodes gestuurd. CobbleDB gebruikt RocksDB MultiGet voor batchopvragingen, geeft bij voorkeur een replica in dezelfde beschikbaarheidszone de opdracht en kan een andere replica aanspreken wanneer een node traag reageert.
Honderden codeeragents hielpen, mensen hielden de controle
Perplexity zegt dat twee menselijke engineers CobbleDB in ongeveer twee maanden bouwden met hulp van honderden permanente AI-codeeragents. Die agents hielpen bij code-inspectie, tests, reparaties, documentatie en het vasthouden van projectcontext.
De menselijke engineers bepaalden de architectuur, beoordeelden ingrijpende wijzigingen en autoriseerden productiebewerkingen. Dat onderscheid is belangrijk: AI-agents versnelden delen van het ontwikkelwerk, maar de beschreven productie-infrastructuur werd niet zelfstandig door agents ontworpen en beheerd.
De prijs van snelheid en een lagere opslagraming
Perplexity’s interne kostenmodel raamt de opslaglaag van CobbleDB op minstens 20 procent lagere kosten dan DynamoDB in alle beoordeelde commitmentniveaus. Die raming gaat over de opslaglaag en laat de engineering- en onderhoudskosten van de eigen database buiten beschouwing.
Daar staat een bewuste beperking tegenover. CobbleDB heeft voor deze hot-store-taak geen transacties of gesynchroniseerde replica’s nodig en accepteert een korte vertraging tussen het schrijven van een document en de beschikbaarheid ervan bij het lezen. Voor Perplexity’s voorbereide zoekrecords past die keuze bij de workload; systemen die sterke consistentie of complexe transacties vereisen, hebben een ander eisenpakket.
Wat Perplexity zegt dat hierna komt
Perplexity zegt CobbleDB open source te willen maken, zodat andere teams die AI-zoeksystemen bouwen dezelfde opslaglaag kunnen gebruiken. Het project blijft in de beschreven architectuur ondertussen een gespecialiseerde productiedatabase voor een afgebakende zoektaak.
