Perplexity costruisce CobbleDB per accelerare la ricerca basata sull’IA

Il 14 settembre 2026 Perplexity ha presentato CobbleDB, un key-value store distribuito progettato per servire rapidamente pagine web già elaborate durante le ricerche con IA. Nel percorso di ricerca interessato, la società riporta una riduzione della latenza mediana dei batch da 31,4 a 5,60 millisecondi e del p99 da 123 a 24,2 millisecondi. Il risultato arriva da un database costruito per un compito molto preciso, non da un sostituto universale dei database gestiti.

Perplexity ha costruito CobbleDB per un solo lavoro, ma molto impegnativo

CobbleDB conserva record di pagine preparati in anticipo: le chiavi sono identificatori di pagina sottoposti ad hashing, mentre i valori contengono passaggi già suddivisi e embedding vettoriali associati a ciascun segmento. Quando una ricerca deve recuperare molte pagine, il sistema può leggere questi dati in batch invece di ricostruirli durante la richiesta.

Perplexity usa CobbleDB in una parte dell’architettura di ricerca che in precedenza impiegava DynamoDB. Questo non equivale a una sostituzione di DynamoDB in tutta l’infrastruttura dell’azienda: il perimetro descritto riguarda il servizio di ricerca e i carichi selezionati che richiedono letture ripetute di dati già preparati.

La differenza progettuale è importante. Un database generalista deve gestire molti tipi di accesso e vincoli; CobbleDB rinuncia a parte di quella flessibilità per controllare più direttamente partizionamento, cache, instradamento e repliche nel percorso di lettura che interessa a Perplexity.

I numeri sulla latenza sono notevoli, ma arrivano da un confronto prima-dopo

Le misurazioni di produzione riportate da Perplexity sono state raccolte prima e dopo la migrazione, con traffico osservato in momenti diversi. Non si tratta quindi di un test controllato con richieste identiche eseguite simultaneamente sui due sistemi.

Il passaggio da 31,4 a 5,60 ms corrisponde a una riduzione di circa l’82,2%. Il traffico associato alle misurazioni era di circa 200.000 richieste al secondo. In un successivo test di carico, Perplexity ha riportato un raggiungimento di 500.000 richieste al secondo prima che le prestazioni iniziassero a peggiorare: è un risultato di laboratorio, non un dato di traffico di produzione sostenuto.

Come si dividono il lavoro Pillar, Lorry e CobbleDB

Il sistema separa tre funzioni che prima erano più accoppiate: conservare lo stato durevole dei documenti, preparare gli aggiornamenti e servire rapidamente i dati durante la ricerca.

Pillar stabilisce quali sottoinsiemi di pagine devono essere esportati. Lorry produce file specifici per partizione e li registra per l’importazione. Le repliche di CobbleDB possono applicare gli aggiornamenti in autonomia e recuperare gli arretrati senza bloccare l’intero sistema.

Durante una ricerca, un router senza stato sottopone le chiavi ad hashing, raggruppa le richieste per partizione e le invia in parallelo. CobbleDB preferisce una replica nella stessa zona di disponibilità quando possibile; se una lettura è lenta, può interrogare un’altra replica. L’API RocksDB MultiGet consente di recuperare più elementi con una singola operazione logica.

Centinaia di agenti AI hanno aiutato a scriverlo, ma gli esseri umani hanno mantenuto il controllo

Il nucleo di CobbleDB conta circa 40.000 righe di Rust. Perplexity afferma che due ingegneri lo hanno sviluppato in circa due mesi con l’assistenza di centinaia di agenti di coding persistenti.

Gli agenti hanno contribuito all’ispezione del codice, alla ricerca dei rischi, alla preparazione di test e correzioni, alla documentazione e al mantenimento del contesto del progetto. Gli ingegneri hanno invece definito l’architettura, esaminato le modifiche più delicate e autorizzato le operazioni in produzione. La formula, quindi, è quella di uno sviluppo fortemente assistito dall’IA, non di un database messo in produzione senza supervisione umana.

Il prezzo della velocità è un sistema più specializzato da gestire

Perplexity stima che CobbleDB riduca di almeno il 20% il costo del livello di storage rispetto a DynamoDB in tutti i livelli di impegno valutati. Si tratta di un modello interno basato sulle dimensioni dello storage e sulle capacità di lettura e scrittura considerate per quel carico; il calcolo non include il lavoro di sviluppo e manutenzione del database personalizzato né la gestione dei guasti.

La stessa specializzazione impone un compromesso sul modello di consistenza. Per il percorso di servizio descritto, CobbleDB non richiede transazioni né repliche sincronizzate e accetta un breve intervallo tra la scrittura di un documento e la sua disponibilità in lettura. È una scelta coerente con dati preparati per la ricerca, ma non una caratteristica da trasferire automaticamente a sistemi che richiedono consistenza forte o transazioni complesse.

Ogni partizione dispone di tre repliche su tre nodi differenti. I dati già presenti nella cache vengono serviti dalla memoria; quelli non memorizzati in cache arrivano dallo storage NVMe locale. Il controllo diretto di questi componenti può favorire il percorso di lettura, ma lascia a Perplexity la responsabilità dell’intero datastore e dell’infrastruttura che lo sostiene.

Cosa intende fare Perplexity con CobbleDB

Perplexity ha dichiarato di voler rendere CobbleDB open source, con l’obiettivo di permettere ad altri team che costruiscono sistemi di ricerca nativi per l’IA di adottare lo stesso livello di storage.