Em 14 de setembro de 2026, a Perplexity detalhou o CobbleDB, um armazenamento distribuído de chave-valor criado para servir páginas pré-processadas durante consultas de busca com IA. Na comparação antes e depois divulgada pela empresa, a latência mediana de leituras em lote caiu de 31,4 ms para 5,60 ms, uma redução de aproximadamente 82,2%. O p99 passou de 123 ms para 24,2 ms.
O ganho vem de uma escolha deliberadamente estreita: o CobbleDB não tenta ser um banco de dados de uso geral. Ele guarda passagens já divididas em trechos e seus embeddings vetoriais — representações numéricas usadas para aproximar conteúdos semanticamente — e os entrega em grandes lotes quando a busca precisa deles.
Um banco de dados feito para uma tarefa específica
O CobbleDB substituiu o DynamoDB em parte da arquitetura de atendimento da busca da Perplexity. A mudança não corresponde a uma troca geral de todos os usos de banco de dados da empresa: o sistema foi desenhado para uma carga de trabalho específica, com leituras repetidas de registros preparados por um pipeline assíncrono.
As chaves são identificadores de páginas submetidos a hash. Os valores armazenam os trechos pré-processados e os embeddings de cada trecho. Uma solicitação da API de busca costuma reunir aproximadamente 100 a 120 chaves, que são divididas em lotes menores para a recuperação paralela.
O núcleo tem aproximadamente 40.000 linhas de Rust e usa o RocksDB como mecanismo embutido de armazenamento. Registros em cache são atendidos pela memória; os demais vêm do armazenamento NVMe local dos nós de dados. Cada partição mantém três réplicas em três nós diferentes.
Os ganhos de latência relatados pela Perplexity
A Perplexity mediu o desempenho em produção com cerca de 200.000 solicitações por segundo. A empresa comparou o período anterior, com DynamoDB, ao período posterior à migração para CobbleDB:
| Métrica | DynamoDB antes da migração | CobbleDB depois da migração | Contexto da medição |
| Latência mediana de leitura em lote | 31,4 ms | 5,60 ms | Comparação antes e depois em produção |
| Percentil 90 (p90) | 56,7 ms | 9,77 ms | Comparação antes e depois em produção |
| Percentil 99 (p99) | 123 ms | 24,2 ms | Comparação antes e depois em produção |
A comparação é relevante para uma busca com IA porque cada resposta pode depender da recuperação de muitos registros em sequência. Ainda assim, os números vêm de períodos diferentes, antes e depois da migração, e não de um teste simultâneo com tráfego idêntico. A própria Perplexity também relatou um teste de carga de até 500.000 solicitações por segundo, antes de o desempenho começar a cair; esse resultado não equivale a tráfego de produção sustentado.
Como Pillar, Lorry e CobbleDB dividem o trabalho
A arquitetura separa responsabilidades que antes ficavam mais acopladas. O desenho funciona como uma linha de montagem: uma camada mantém o documento completo, outra prepara os pacotes de atualização e a terceira atende as consultas com baixa latência.
| Componente | Função na arquitetura descrita | Tecnologia relacionada |
| Pillar | Mantém o estado durável e versionado dos documentos, incluindo metadados, trechos e embeddings | YTsaurus e armazenamento em HDD |
| Lorry | Lê a fila de exportação, cria lotes alinhados às partições e os entrega ao CobbleDB | Amazon S3 como plano de dados |
| CobbleDB | Ingere os lotes e atende as leituras preparadas durante as consultas | RocksDB, memória e NVMe local |
O Pillar decide quais subconjuntos de páginas devem ser exportados. O Lorry transforma esses registros em arquivos específicos de cada partição e os registra para ingestão. As réplicas do CobbleDB aplicam os lotes de forma independente e em ordem cronológica, permitindo que uma réplica atrasada se recupere sem bloquear as demais.
Durante uma consulta, um roteador sem estado transforma as chaves em partições, agrupa as leituras e envia os pedidos em paralelo. O sistema prioriza uma réplica na mesma zona de disponibilidade e pode consultar outra quando um nó demora a responder. Para recuperar vários registros de uma vez, usa a operação MultiGet do RocksDB.
Centenas de agentes ajudaram, mas humanos mantiveram o controle
O CobbleDB foi desenvolvido em aproximadamente dois meses por dois engenheiros humanos com a ajuda de centenas de agentes de programação persistentes. Os agentes auxiliaram na inspeção do código, na identificação de riscos, na preparação de testes e correções, na documentação e na continuidade do trabalho.
A Perplexity afirma que os engenheiros definiram a arquitetura, revisaram mudanças de maior consequência e autorizaram as operações em produção. A divisão é importante: acelerar a escrita e a revisão de código não equivale a delegar aos agentes a decisão final sobre a infraestrutura que atende o tráfego real.
A troca por trás da velocidade e da economia projetada
O CobbleDB abre mão de transações e de réplicas sincronizadas para a carga de trabalho descrita. A Perplexity considera aceitável um pequeno intervalo entre a gravação de um documento e sua disponibilidade para leitura nesse caminho de atendimento.
Isso torna o sistema adequado ao serving de dados preparados, mas delimita seu alcance. Uma aplicação que dependa de consistência forte, transações complexas ou do conjunto de recursos de um serviço gerenciado não está lidando com o mesmo tipo de problema.
No custo, o modelo interno da Perplexity estima uma economia de pelo menos 20% sobre o DynamoDB em todas as categorias de compromisso avaliadas. A conta considera a camada de armazenamento e exclui os custos de engenharia e manutenção de operar um banco de dados próprio. A velocidade vem acompanhada de responsabilidade operacional — não existe botão mágico quando o serviço é seu.
O próximo passo planejado
A Perplexity planeja abrir o código do CobbleDB para que outras equipes que desenvolvem sistemas de busca com IA possam usar a camada de armazenamento. O plano foi apresentado junto com o detalhamento técnico do sistema em 14 de setembro de 2026.
