Deve-se armazenar os vetores de embeddings numa base PostgreSQL através da extensão pgvector, ou confiar essa tarefa a uma base de dados vetorial dedicada? Um guia técnico propõe responder à questão com medições de desempenho em vez de argumentos de princípio, comparando o pgvector com o Qdrant.
Duas arquiteturas, um mesmo objetivo
pgvector é uma extensão de código aberto para PostgreSQL, na versão 0.8.6, compatível com PostgreSQL 13 e versões posteriores, de acordo com o seu repositório oficial no GitHub. Adiciona à base um tipo de coluna dedicado a vetores, bem como pesquisas exatas e aproximadas de vizinhos mais próximos. Concretamente, um embedding, ou seja, a representação numérica de um conteúdo sob a forma de vetor, pode ser armazenado na mesma tabela que os dados a que se refere, e consultado com a linguagem SQL habitual. São propostas cinco funções de distância, incluindo o cosseno e o produto escalar.
Uma base de dados vetorial dedicada é, pelo contrário, um serviço distinto, dotado do seu próprio motor de armazenamento e concebido em torno da pesquisa vetorial. O guia menciona nomeadamente Pinecone, Qdrant, Weaviate, Milvus e ChromaDB. Esta escolha de arquitetura implica implementar, monitorizar e fazer cópia de segurança de um sistema adicional, e mantê-lo sincronizado com a base que contém os dados de referência.
Medições locais, depois em grande escala
O guia propõe um teste reproduzível num computador portátil, com Docker, Python 3.10 ou uma versão posterior e cerca de 8 GB de RAM livre. O conjunto de dados é sintético: 100 000 vetores de 1536 dimensões, ou seja, o tamanho de um modelo de embeddings comum, carregados nos dois sistemas com os mesmos parâmetros de índice HNSW. Num hardware deste tipo, as latências situam-se, segundo o autor, entre alguns milissegundos e algumas dezenas de milissegundos, com fortes variações consoante o processador e a memória disponíveis. Este volume continua demasiado modesto para tirar uma conclusão de produção.
Para esta questão, o guia baseia-se num estudo publicado pela Tiger Data. Este incide sobre 50 milhões de embeddings Cohere de 768 dimensões, testados em máquinas AWS r6id.4xlarge (16 vCPU, 128 GB de RAM), com uma versão modificada da ferramenta ANN-Benchmarks. O guia salienta um ponto importante: o teste foi realizado com pgvector associado a pgvectorscale, uma extensão da Timescale que adiciona outro tipo de índice, StreamingDiskANN, e não com pgvector sozinho.
De acordo com estes resultados, com uma recuperação (recall) de 99%, o PostgreSQL com pgvectorscale atinge 471,57 pedidos por segundo, contra 41,47 do Qdrant. A latência mediana é quase idêntica, com 31,07 ms contra 30,75 ms. O Qdrant distingue-se, no entanto, nas latências extremas: o seu p99 é de 38,71 ms, contra 74,60 ms, e o seu índice foi construído em 3,3 horas, contra 11,1 horas. Para o guia, os dois sistemas mantêm-se abaixo dos 100 ms em todos os percentis medidos.
Que escolha consoante a carga de trabalho
O guia considera que o pgvector é adequado para volumes até cerca de 5 a 10 milhões de vetores, com uma concorrência de pedidos moderada e quando uma equipa já domina o PostgreSQL. Destaca também a consistência transacional entre dados relacionais e vetores, que permite atualizar um documento e o seu vetor numa mesma transação.
Pelo contrário, uma base dedicada justifica-se, segundo o artigo, para volumes de várias centenas de milhões a vários milhares de milhões de vetores, ou para uma restrição estrita de latência extrema em pesquisas filtradas muito solicitadas, domínio onde o Qdrant apresenta a vantagem medida. O Milvus é mencionado pela indexação acelerada por GPU, e o Pinecone por ser um serviço totalmente gerido, sem administração interna necessária.
