O LanceDB carregou 100 mil embeddings da OpenAI 22 vezes mais rápido que o pgvector, enquanto o pgvector respondeu à mesma carga de trabalho de oito clientes simultâneos 1,8 vez mais rápido. A diferença na latência de thread única e na eficiência de armazenamento também favoreceu o LanceDB, oferecendo aos desenvolvedores uma maneira baseada em dados para escolher um banco de dados vetorial.

Por que um benchmark é importante agora

A busca vetorial saiu dos laboratórios de pesquisa para serviços de produção, como mecanismos de recomendação e geração aumentada de recuperação (RAG). A maioria das equipes já utiliza PostgreSQL, portanto, a extensão pgvector promete busca por similaridade sem a necessidade de nova infraestrutura. No entanto, bancos de dados dedicados como o LanceDB prometem menor latência e armazenamento mais barato. As equipes devem escolher entre "adicionar ao que já temos" e "executar um motor especializado", uma decisão que impacta o custo e o desempenho à medida que os conjuntos de dados crescem e as taxas de requisição aumentam.

Como o teste foi configurado

Ambos os sistemas indexaram os mesmos 100 mil vetores, cada um com 1536 dimensões, gerados pelo modelo de embedding da OpenAI. Medimos a velocidade de ingestão, o uso de disco, a latência de consulta de thread única e o throughput com oito clientes simultâneos.

Resultados comparativos

  • Velocidade de ingestão – O LanceDB registrou uma vantagem de 22x.
  • Ocupação de disco – O LanceDB armazenou os vetores ocupando aproximadamente um terço do espaço usado pelo pgvector.
  • Latência de thread única – As consultas foram cerca de duas vezes mais rápidas no LanceDB.
  • Escalabilidade de concorrência – Com oito clientes paralelos, o pgvector entregou um throughput 1,8x maior que o LanceDB.

Raízes arquiteturais das diferenças

O LanceDB é uma biblioteca embarcada que roda dentro do processo Python que hospeda a aplicação. Todas as operações permanecem dentro do processo, de modo que os dados nunca cruzam um limite de rede e o índice é atualizado com overhead mínimo. Esse design se destaca para cargas de trabalho de tarefa única, mas atinge um limite quando múltiplas threads Python disputam o Global Interpreter Lock (GIL), que bloqueia a execução paralela real do bytecode Python.

O pgvector estende o PostgreSQL no lado do servidor. Cada conexão de cliente inicia um processo de servidor separado, contornando totalmente o GIL. O planejador do PostgreSQL decide como satisfazer uma busca por similaridade, e o servidor pode iniciar muitos processos para atender requisições simultâneas. Esse isolamento explica o melhor escalonamento sob carga.

Particularidades de filtragem e planejamento de consulta

Pipelines de RAG do mundo real frequentemente combinam similaridade vetorial com filtros tradicionais (ex: WHERE user_id = 42). O LanceDB aplica um pré-filtro que se comporta de forma previsível entre as execuções. O pgvector depende do planejador de consultas do PostgreSQL, que pode escolher um scan de índice rápido ou recorrer a um scan exato mais lento, dependendo das estatísticas. Executar ANALYZE após o carregamento em massa de uma tabela pgvector atualiza essas estatísticas; sem isso, o recall pode cair para quase zero, quebrando efetivamente a busca.

Quando cada opção faz sentido

Escolha o pgvector se

  • Sua stack já inclui PostgreSQL e você quer evitar adicionar outro serviço.
  • Você espera muitos usuários simultâneos ou chamadas de API.
  • Garantias ACID e ferramentas de DBA familiares forem importantes.

Escolha o LanceDB se

  • Seu fluxo de trabalho for um pipeline de ML que ingere novos embeddings com frequência.
  • Você precisar do caminho de escrita mais rápido e baixa latência para agentes de requisição única (ex: chatbots).
  • O custo de disco for uma preocupação e você puder tolerar o limite de desempenho de thread única.

Resumo: Se a velocidade bruta de ingestão, o armazenamento mínimo e a latência de requisição única forem o que mais importa, o LanceDB vence. Se você precisa atender muitos usuários ao mesmo tempo e depende de uma implantação existente do PostgreSQL, a vantagem de concorrência do pgvector o torna a escolha mais segura. Use os números deste benchmark para alinhar o banco de dados à métrica mais crítica do seu produto.