Le 14 septembre 2026, Perplexity a détaillé CobbleDB, un magasin clé-valeur distribué conçu pour servir les données préparées par son moteur de recherche IA. La société rapporte une baisse de la latence médiane des lectures groupées, de 31,4 ms avec DynamoDB à 5,60 ms avec CobbleDB, dans une mesure avant-après réalisée avec du trafic de production. Le gain est spectaculaire, mais il concerne un chemin de lecture très précis, pas une base de données universelle.
Perplexity a construit CobbleDB pour une seule charge de recherche
CobbleDB stocke des identifiants de pages hachés et les données préparées associées : passages découpés à l’avance et embeddings vectoriels pour chaque segment. Ces embeddings représentent le contenu sous forme numérique afin de faciliter la recherche sémantique.
Perplexity l’utilise pour récupérer rapidement des lots de pages déjà traitées au moment où une requête de recherche est servie. La base a donc été conçue pour des lectures répétées et prévisibles, plutôt que pour couvrir tous les usages d’une base généraliste. CobbleDB remplace DynamoDB sur une partie de l’architecture de service de recherche de Perplexity ; cette évolution ne concerne pas tous les usages internes de DynamoDB.
Le cœur du système compte environ 40 000 lignes de Rust. Chaque partition possède trois répliques réparties sur trois nœuds. Les données mises en cache sont servies depuis la mémoire, tandis que les données non présentes en cache sont lues sur du stockage NVMe local via RocksDB.
Des lectures nettement plus rapides, selon les mesures de Perplexity
Perplexity rapporte les résultats suivants pour ses lectures groupées en production :
| Indicateur | DynamoDB avant la migration | CobbleDB après la migration |
| Latence médiane | 31,4 ms | 5,60 ms |
| Latence p90 | 56,7 ms | 9,77 ms |
| Latence p99 | 123 ms | 24,2 ms |
La latence médiane diminue ainsi d’environ 82,2 % entre les deux périodes mesurées. La comparaison a été réalisée avant puis après la migration, avec des périodes de trafic différentes, et non au moyen d’un test simultané sur des requêtes identiques. Les chiffres décrivent donc le résultat observé par Perplexity dans son environnement de production, pas un benchmark indépendant contrôlé.
Les mesures de latence correspondent à environ 200 000 requêtes par seconde. Perplexity rapporte aussi un test de charge ayant atteint 500 000 requêtes par seconde avant que les performances commencent à se dégrader. Ce résultat de charge n’est pas présenté comme un débit de production soutenu.
Comment Pillar, Lorry et CobbleDB se partagent le travail
Le système sépare trois fonctions qui étaient auparavant davantage couplées : conserver l’état durable des documents, préparer les mises à jour et servir les lectures rapides.
| Composant | Fonction dans l’architecture | Technologie associée |
| Pillar | Conserve l’état versionné des documents, leurs métadonnées, leurs passages et leurs embeddings | YTsaurus et stockage sur disques durs |
| Lorry | Transforme les exports en lots alignés sur les partitions et les transmet à CobbleDB | Amazon S3 pour le transport des données |
| CobbleDB | Ingère les lots et sert les enregistrements préparés au moment de la recherche | Rust, RocksDB, mémoire et NVMe local |
Pillar détermine les sous-ensembles de pages à exporter. Lorry lit une file persistante alignée sur les partitions, crée des fichiers de lots et les enregistre pour CobbleDB. Les répliques récupèrent ensuite ces lots et les appliquent dans l’ordre chronologique, ce qui permet à une réplique ralentie de rattraper son retard sans bloquer les autres.
Au moment de la requête, un routeur sans état hache les identifiants de pages, regroupe les lectures par partition et les envoie en parallèle. CobbleDB privilégie une réplique située dans la même zone de disponibilité et peut solliciter une autre réplique lorsqu’un nœud répond lentement. L’API de lecture groupée s’appuie sur RocksDB MultiGet.
Des centaines d’agents ont aidé, mais les humains ont gardé le contrôle
Perplexity indique que deux ingénieurs humains ont développé CobbleDB en environ deux mois avec l’aide de centaines d’agents de codage persistants. Les agents ont participé à l’inspection du code, à la détection de risques, aux tests, aux corrections, à la documentation et au suivi des tâches.
Les ingénieurs humains ont toutefois défini l’architecture, examiné les changements importants et autorisé les opérations en production. CobbleDB n’est donc pas présenté comme une base entièrement construite et opérée de façon autonome par des agents : les agents ont accéléré une partie du travail, tandis que la responsabilité technique et opérationnelle est restée humaine.
Le gain de vitesse s’accompagne d’un coût opérationnel
Perplexity estime que CobbleDB réduit d’au moins 20 % le coût de la couche de stockage par rapport à DynamoDB, selon son modèle interne et les différents niveaux d’engagement évalués. Cette estimation exclut les coûts d’ingénierie et de maintenance liés à l’exploitation d’une base développée sur mesure, notamment la gestion des défaillances.
Le compromis concerne aussi la cohérence des données. Pour cette charge de service, CobbleDB ne requiert ni transactions ni répliques synchronisées : un court délai entre l’écriture d’un document et sa disponibilité en lecture est accepté. Ce choix convient au chemin de recherche décrit par Perplexity, mais ne correspond pas aux besoins d’une application qui exige des transactions complexes ou une cohérence forte.
Perplexity prévoit une publication open source
Perplexity prévoit de publier CobbleDB en open source afin que d’autres équipes travaillant sur des systèmes de recherche conçus pour l’IA puissent réutiliser cette couche de stockage.
