--- title: "Perplexity troca o DynamoDB por um banco próprio e reduz a latência em cinco vezes" author: "Gabriela P. Torres" date: "2026-09-26 06:45:00-03" category: "Inteligência Artificial & Dados" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/26/perplexity-troca-o-dynamodb-por-um-banco-proprio-e-reduz-a-latencia-em-cinco-vezes/md" --- ## Resumo - A Perplexity substituiu o DynamoDB pelo CobbleDB para adaptar a camada de leitura aos padrões de consultas usados por sistemas de inteligência artificial. - O CobbleDB trabalha com lotes de 10 a 20 chaves e recupera chunks de documentos e embeddings com tamanho médio de 50 KB. - A arquitetura separa o estado durável, administrado pelo Pillar, do processamento em lote feito pelo Lorry e da leitura rápida atendida pelo CobbleDB. - A latência mediana caiu de 31,4 ms para 5,6 ms, enquanto o p99 passou de 123 ms para 24,2 ms. - A Perplexity estima economia de pelo menos 20% nos custos de armazenamento em relação ao DynamoDB. - Aravind Srinivas afirmou que a migração pode gerar economia de até US$ 100 milhões por ano. - O código do CobbleDB deve ser disponibilizado como open source em breve, mas ainda não há data informada. --- A **Perplexity** substituiu seu banco de dados anterior pelo **CobbleDB** para acelerar a leitura de documentos usados em suas respostas de pesquisa. Nos números divulgados pela empresa, a latência mediana caiu de **31,4 ms para 5,6 ms**, enquanto a medição do percentil 99 passou de 123 ms para 24,2 ms. A mudança também foi associada a uma estimativa de pelo menos 20% de economia nos custos de armazenamento. O ponto que merece ser desbugado é simples: a promessa não depende apenas de trocar uma ferramenta por outra, mas de adaptar toda a arquitetura ao modo como a inteligência artificial consulta dados. [A explicação oficial da arquitetura](https://www.perplexity.ai/hub/blog/cobbledb) ajuda a separar o que foi medido do que ainda é estimativa. ## O problema estava no padrão de leitura O CobbleDB foi criado porque as leituras usadas em aplicações de inteligência artificial têm um formato diferente da busca convencional. Em vez de depender apenas de consultas isoladas, o sistema trabalha com lotes de **10 a 20 chaves** por vez, isto é, identificadores usados para localizar registros em um banco de dados. Se a aplicação precisa reunir várias partes de um documento para produzir uma resposta, então a capacidade de buscar esses registros em conjunto passa a ter mais peso do que a simples velocidade de uma consulta individual. É essa característica que explica por que a Perplexity redesenhou a camada de leitura em vez de apenas aumentar a infraestrutura anterior. Esses lotes extraem **chunks de documentos**, que são trechos menores separados de um arquivo maior, e embeddings, representações numéricas usadas para relacionar conteúdos semelhantes. A fonte informa que cada embedding tem tamanho médio de **50 KB**, uma dimensão que ajuda a explicar por que a transferência e a localização dos dados entram diretamente na conta de latência. O CobbleDB foi desenvolvido como um banco de dados distribuído de chave-valor em Rust, modelo no qual cada informação é localizada por uma chave associada ao seu valor. A escolha, portanto, foi moldada pelo tipo de leitura que a pesquisa com IA exige, e não por uma preferência abstrata por trocar de fornecedor. ## Como a arquitetura foi reorganizada A nova arquitetura separa duas responsabilidades que antes poderiam disputar os mesmos recursos: guardar o estado que precisa permanecer disponível e preparar os dados para serem lidos rapidamente. O sistema **Pillar** administra o estado durável, enquanto o **Lorry** realiza a agregação em lote, reunindo os dados que serão consultados em conjunto. Em termos práticos, um componente cuida da permanência das informações e o outro organiza a entrega dos lotes. Essa divisão prepara o terreno para a terceira camada, que recebe as consultas de baixa latência sem assumir sozinha todo o trabalho de armazenamento durável. É nessa terceira camada que entra o **CobbleDB**, usado como hot-store, expressão que designa um armazenamento voltado para leituras rápidas. O sistema funciona como a parte da arquitetura que atende diretamente aos fetches de conteúdo web, ou seja, às operações de recuperação de trechos já armazenados. A separação permite que a camada de leitura seja ajustada ao padrão de lotes da pesquisa com IA, enquanto o estado durável permanece sob outra responsabilidade. Se o objetivo principal é diminuir o tempo entre a solicitação e a entrega do documento, então concentrar essa função em uma camada própria torna a medição mais clara e o gargalo mais fácil de localizar. Para sustentar essa camada de leitura, o projeto usa **RocksDB** e armazenamento local em **NVMe**. RocksDB é o mecanismo empregado para organizar os dados localmente, enquanto NVMe é um padrão de armazenamento de alta velocidade conectado diretamente ao servidor. A arquitetura oficial descreve essa combinação como parte do hot-store de baixa latência. O ganho alegado não vem de uma única configuração mágica: ele resulta da aproximação entre os dados consultados e o processo que precisa lê-los, reduzindo a dependência de uma camada remota para cada operação. O banco foi implementado em **Rust**, uma linguagem de programação usada no desenvolvimento do serviço. A informação aparece junto da descrição do projeto interno, que foi criado especificamente para os padrões de leitura da Perplexity. Essa escolha não prova, sozinha, a existência de uma vantagem de desempenho, e seria um erro transformar o nome da linguagem em explicação completa para os resultados. O dado verificável é outro: o código foi construído para combinar leituras em lote, armazenamento local e um serviço dedicado à recuperação rápida dos documentos. ## O que os números realmente mostram A principal métrica divulgada foi a latência mediana, que caiu de **31,4 ms para 5,6 ms** após a migração. A mediana mostra o ponto central das medições realizadas, portanto o resultado indica que a consulta típica ficou muito mais rápida. A diferença equivale a uma redução de aproximadamente cinco vezes no tempo observado, embora a conta exata entre os dois números seja superior a esse fator. A [análise técnica publicada pela InfoQ](https://www.infoq.com/news/2026/09/cobbledb-perplexity) registra essa comparação e vincula a mudança ao uso de leituras em lote para documentos e embeddings. A segunda comparação olha para a parte mais lenta das consultas. A latência p99, métrica usada para observar o comportamento de 99% das requisições e deixar visível a cauda de maior demora, caiu de **123 ms para 24,2 ms**. Esse número importa porque uma mediana baixa pode esconder uma parcela de solicitações muito mais lentas. Se a mediana mede a experiência típica e o p99 revela o atraso entre as requisições mais demoradas, então os dois resultados juntos oferecem uma leitura menos promocional da melhoria: o avanço apareceu tanto no centro da distribuição quanto na sua extremidade mais lenta. O desenho também inclui um roteador que prioriza réplicas na **mesma zona**, reduzindo a distância entre a consulta e a cópia de dados escolhida para respondê-la. A comunicação oficial informa ainda que o recurso multi-get do **RocksDB** é usado para eliminar overhead de rede, isto é, trabalho adicional de comunicação entre componentes. Esses mecanismos não devem ser confundidos com a própria queda de latência: eles são partes da implementação que ajudam a explicar como a arquitetura tenta atender várias chaves de uma vez. A empresa apresentou a combinação como resposta direta ao padrão de leitura dos sistemas de pesquisa com IA. Na dimensão financeira, a Perplexity estima uma economia de pelo menos **20% nos custos de armazenamento** em relação ao DynamoDB. Esse número é uma projeção da empresa, não uma medição independente apresentada no material fornecido. Em outra declaração, o CEO **Aravind Srinivas** afirmou que a migração poderia gerar uma economia de até US$ 100 milhões por ano. As duas cifras não significam a mesma coisa: a primeira trata da comparação de custos de armazenamento, enquanto a segunda é uma estimativa anual para a companhia. Se o cálculo de 20% descreve uma categoria de despesa, então os US$ 100 milhões dependem de uma conta mais ampla sobre a operação total. ## Agentes de IA aceleraram a construção O desenvolvimento do CobbleDB foi concluído em **dois meses** por dois engenheiros com o auxílio de centenas de agentes de codificação autônomos e proativos. A informação também foi confirmada pela própria Perplexity em sua comunicação pública. Agentes de codificação são sistemas de inteligência artificial usados para ajudar a produzir ou revisar código, mas a existência deles não elimina a participação dos engenheiros descritos na fonte. O fato relevante, em termos de processo, é a combinação entre uma equipe humana pequena e uma grande quantidade de agentes durante a construção da infraestrutura. A velocidade do desenvolvimento precisa ser separada do resultado operacional. O que os dados permitem afirmar é que a arquitetura foi criada em dois meses e que as medições posteriores registraram queda na latência mediana e no p99. Não é possível concluir, apenas a partir desses fatos, que qualquer banco de dados possa ser substituído no mesmo prazo ou que agentes autônomos produzam o mesmo resultado em cargas diferentes. A leitura mais precisa é condicional: se o padrão de acesso é conhecido e a equipe consegue testar a implementação, então a automação pode acelerar a construção; senão, o prazo divulgado não funciona como garantia geral. ## O próximo teste será abrir o código A Perplexity informou que pretende tornar o código do **CobbleDB open source** em breve. Open source significa que o código é disponibilizado sob condições que permitem seu acesso e uso conforme a licença adotada, mas a fonte não informa uma data específica nem apresenta a licença planejada. Por isso, a promessa deve ser registrada como intenção futura, não como lançamento já concluído. Quando o código estiver disponível, será possível verificar com mais detalhes como funcionam as leituras em lote, o roteamento entre réplicas e a integração com o armazenamento local. Até esse próximo passo, a caixa de ferramentas para interpretar o anúncio é separar três camadas de evidência: o desempenho medido, a economia estimada e a abertura futura do código. O desempenho tem números comparáveis, de **31,4 ms para 5,6 ms** na mediana e de 123 ms para 24,2 ms no p99. A redução de custos foi projetada em pelo menos 20%, enquanto a economia anual de até US$ 100 milhões foi apresentada por Srinivas como uma possibilidade financeira. O CobbleDB já tem uma arquitetura descrita; a verificação independente de suas promessas dependerá do código open source anunciado e de novas medições disponíveis para análise.