Alternativas ao Pinecone: uma comparação das opções

O nosso interesse é insignificante e é mencionado apenas por uma questão de formalidade: somos a Geonode e comercializamos proxies, o que não tem nada a ver com nada disto. Não ganhamos nada, independentemente da opção que escolher, o que é uma posição mais rara nesta categoria do que deveria ser — a maioria das comparações deste tipo é publicada por um dos fornecedores que estão a ser comparados. Todos os valores abaixo provêm da própria página de preços ou repositório do fornecedor, verificados em setembro de 2026, e as licenças provêm dos próprios repositórios dos projetos, em vez de páginas de marketing.

Quatro categorias, não apenas uma

Antes de comparar produtos, determine em que categoria está a procurar. Não são substitutos uns dos outros.

Bases de dados vetoriais geridas. Pinecone, Qdrant Cloud, Weaviate Cloud, Zilliz Cloud, Chroma Cloud. Envia dados e consultas; outra entidade gere o índice. Adequado para escalabilidade, multilocação e equipas que preferem não gerir infraestruturas distribuídas.

Bases de dados vetoriais auto-hospedadas. Qdrant, Weaviate, Milvus, Chroma — todas as quatro são de código aberto e podem ser executadas no seu próprio hardware. Adequado para requisitos de residência de dados, custos previsíveis à escala e organizações que já gerem infraestrutura.

Extensões para uma base de dados que já possui. O pgvector adiciona pesquisa de similaridade vetorial ao Postgres. Adequado para o caso muito comum em que já utiliza o Postgres e adicionar um segundo armazenamento de dados é a parte dispendiosa.

Sem base de dados. Uma matriz na memória ou uma biblioteca incorporada. Adequa-se a pequenos corpora, que são mais comuns do que as pessoas imaginam.

O resto deste artigo aborda cada um desses pontos.

As opções geridas

Preços retirados da página de preços de cada fornecedor, verificados em setembro de 2026. Verifique antes de elaborar o orçamento — os preços nesta categoria variam frequentemente.

A análise destas linhas é esclarecedora, porque as unidades de faturação não são comparáveis.

A Pinecone fatura unidades de leitura e escrita. A Weaviate fatura por milhão de dimensões vetoriais, pelo que uma incorporação de 1536 dimensões custa o dobro do que uma de 768 dimensões para o mesmo registo — o que torna a escolha do modelo uma decisão diretamente relacionada com os custos. A Chroma cobra por GiB gravado e por TiB consultado. A Qdrant cobra pelos recursos provisionados.

Não há forma de comparar estas tarifas com base nos valores nominais. A única comparação significativa consiste em modelar a sua própria carga de trabalho — número de registos, número de dimensões, volume de consultas, armazenamento — em relação a cada calculadora de preços. Isso representa uma hora de trabalho e produz habitualmente diferenças de ordem de grandeza em qualquer direção, dependendo da configuração da carga de trabalho.

Duas observações estruturais que vale a pena destacar.

O nível gratuito da Weaviate é genuinamente generoso para avaliação — 100 000 objetos, «sempre gratuito», um cluster por utilizador — e o seu preço baseado em dimensões recompensa modelos de incorporação mais pequenos de uma forma que os outros não fazem.

O plano «Team» da Chroma começa nos 250 dólares/mês mais o custo de utilização, o que representa um valor mínimo consideravelmente mais elevado do que os outros. O seu plano «Starter» custa 0 dólares/mês mais o custo de utilização, com 5 dólares em créditos, pelo que a entrada é suave, mas a transição para o plano superior já não o é.

As opções de alojamento próprio

As quatro principais bases de dados vetoriais de código aberto são genuinamente de código aberto, e as licenças diferem em aspetos que são relevantes para a utilização comercial. Estas informações provêm dos próprios repositórios dos projetos, verificadas em setembro de 2026.

Todos os quatro têm licenças permissivas, o que é o ponto importante: nenhum deles tem copyleft ou restrições de âmbito de utilização que complicariam um produto comercial. Vale a pena referir isto porque não é uma regra universal no mundo das bases de dados e porque a verificação da licença é o tipo de coisa que costuma ser ignorada e que depois se torna um problema no pior momento.

Escolher entre elas, de forma breve e honesta:

Qdrant é a opção a experimentar primeiro se quiser uma base de dados vetorial auto-hospedada e nada mais. Um único binário, Rust, operações simples e um baixo consumo de recursos.

O Milvus foi concebido para distribuição e grande escala, com uma arquitetura correspondentemente mais pesada — múltiplos componentes, uma fila de mensagens e armazenamento de objetos. É potente em grande escala, mas apresenta uma sobrecarga considerável abaixo desse nível.

O Chroma é o mais fácil de começar a utilizar. Funciona «in-process» para desenvolvimento, o que torna a primeira hora muito simples, e é escalável para uma implementação em servidor.

O Weaviate possui o conjunto de funcionalidades mais rico em torno da própria base de dados — módulos para incorporação, reclassificação e pesquisa generativa —, o que pode ser exatamente o que procuras ou mais do que precisas.

Em resumo, para uma implementação auto-hospedada com menos de algumas dezenas de milhões de vetores, todas as quatro opções funcionam; as diferenças são operacionais e não fundamentais, e o fator decisivo é, normalmente, qual delas a sua equipa consegue utilizar com mais facilidade.

pgvector: A resposta subestimada

A opção que se adapta a mais projetos do que qualquer base de dados vetorial dedicada e que recebe menos atenção.

pgvector é uma extensão do Postgres que adiciona tipos vetoriais e pesquisa de similaridade. É de código aberto, amplamente implementada e está disponível como uma oferta gerida em todos os principais serviços Postgres na nuvem — pelo que, para uma grande parte das equipas, não requer qualquer nova infraestrutura.

As vantagens são estruturais, e não técnicas:

Uma base de dados em vez de duas. Os seus vetores coexistem com os seus dados relacionais, na mesma transação, com os mesmos backups, o mesmo controlo de acesso e a mesma monitorização. Isto representa uma poupança operacional maior do que parece.

As junções funcionam. Filtrar resultados vetoriais com base em qualquer elemento do seu esquema relacional é uma cláusula WHERE, em vez de uma funcionalidade de filtragem de metadados com a sua própria semântica e os seus próprios limites.

Sem custos adicionais, se já utiliza o Postgres.

A consistência é gratuita. Gravar um registo e a sua incorporação numa única transação elimina toda uma classe de erros de sincronização que existe em todas as arquiteturas com duas bases de dados.

Os limites são reais e vale a pena conhecê-los:

Escalabilidade. Lida bem com milhões de vetores, mas não foi concebido para milhares de milhões. O ponto de transição depende dos seus padrões de consulta e do seu hardware, e é mais elevado do que o Discourse sugere.

Os tempos de criação de índices e a memória necessária para índices aproximados requerem atenção à medida que a escala aumenta, e o seu ajuste é uma tarefa de administração do Postgres, em vez de uma preocupação do serviço gerido.

Menos funcionalidades específicas de recuperação. Não há reclassificação integrada, nem modelos de incorporação alojados, e a pesquisa híbrida é menos sofisticada do que num sistema concebido especificamente para o efeito — embora a pesquisa de texto completo do Postgres cubra grande parte dessa área.

A regra geral: se já utiliza o Postgres e tem menos do que alguns milhões de vetores, comece por aqui. Pode migrar para um sistema dedicado mais tarde, caso ultrapasse essa capacidade, o que, na maioria dos projetos, não acontece.

Sem qualquer base de dados

A opção que não custa nada e que está certa mais vezes do que se admite.

Para menos de cerca de cem mil vetores, a pesquisa de similaridade por força bruta é suficientemente rápida em hardware comum. Calcular o produto escalar de uma consulta numa matriz de 100 000 × 768 equivale a uma única multiplicação de matrizes — demora milésimos de segundo num portátil e é exato, em vez de aproximado:

import numpy as np

scores = embeddings @ query          # embeddings: (n, d), query: (d,)
top = np.argsort(-scores)[:10]

Essa é toda a implementação. Sem serviço, sem criação de índices, sem custos, sem saltos de rede e sem erros de aproximação.

As bibliotecas incorporadas ampliam a mesma ideia. O FAISS e similares processam milhões de vetores num único processo com índices aproximados, proporcionando-lhe a maior parte do desempenho de uma base de dados de vetores sem ter de gerir uma.

Quando isto deixa de funcionar: quando os dados já não cabem na memória, quando são necessárias gravações simultâneas a partir de vários processos, quando é necessário isolamento multilocatário ou quando o volume de consultas exige escalabilidade horizontal. Esses são limites reais e surgem mais tarde do que as pessoas esperam.

A razão pela qual isto é importante não é a pureza, mas sim o diagnóstico. Começar pelo mais simples significa que, quando a qualidade da recuperação é fraca — o que normalmente acontece no início —, sabe-se que a base de dados não é a causa. A estratégia de fragmentação, a escolha do modelo de incorporação e a formulação da consulta determinam a qualidade da recuperação, e nenhuma delas é melhorada por um serviço gerido.

O que realmente os diferencia

As tabelas de funcionalidades nesta categoria são extensas e, na sua maioria, irrelevantes, uma vez que todos os produtos realizam a pesquisa de similaridade vetorial de forma adequada. Existem cinco aspetos que se diferenciam genuinamente, e são esses que vale a pena comparar com os seus requisitos.

Pesquisa híbrida e a forma como é implementada. Combinar a semelhança semântica com a correspondência exata de palavras-chave é o que salva a recuperação com base em identificadores, códigos de produto e nomes próprios raros — os casos em que a pesquisa vetorial pura é notoriamente fraca. Todos os sistemas suportam agora alguma forma desta pesquisa, e as implementações diferem substancialmente: alguns utilizam um índice esparso separado que tem de ser mantido pelo utilizador, outros oferecem o algoritmo BM25 sobre campos de texto declarados, e outros ainda esperam que o próprio utilizador combine dois conjuntos de resultados. Se o seu corpus contiver algo semelhante a código, teste esta funcionalidade especificamente, em vez de confiar numa simples caixa de seleção.

Semântica da filtragem de metadados. Todos eles filtram com base em metadados; a questão é se a filtragem ocorre antes ou depois da pesquisa aproximada e como isso afeta os seus resultados. A filtragem posterior de um conjunto de resultados «top-k» pode devolver menos de k itens — ou nenhum — quando o filtro é seletivo, o que constitui uma falha surpreendente na primeira vez que ocorre numa consulta de produção. A filtragem prévia evita isso, mas tem um custo mais elevado. Descubra qual é a opção que está a utilizar.

Modelo de multilocação. Espaços de nomes, coleções, índices por locatário ou um campo de metadados. Estes apresentam garantias de isolamento muito diferentes e características de desempenho muito distintas quando o número de locatários é elevado. Se estiver a desenvolver para muitos clientes, esta é a decisão mais difícil de alterar posteriormente.

Comportamento de atualização e eliminação. Alguns sistemas lidam com atualizações frequentes de forma elegante; outros acumulam «tombstones» e necessitam de compactação periódica, o que afeta a latência das consultas. Se os seus dados mudam constantemente — em vez de serem carregados uma vez e lidos —, pergunte explicitamente sobre isto, porque raramente consta numa página de comparação e domina a experiência operacional.

Consistência após a gravação. Se um registo fica imediatamente pesquisável após um «upsert» ou apenas eventualmente. A consistência eventual é perfeitamente razoável para um corpus de documentos, mas bastante irracional para os dados de um utilizador que aparecem nos seus próprios resultados de pesquisa segundos depois de os ter criado.

Nenhuma destas características aparece na tabela de preços, todas podem ser testadas num plano gratuito e qualquer uma delas pode ser a razão pela qual um sistema que parecia perfeito no papel acaba por não se adequar.

Como escolher

Um procedimento de decisão, em vez de uma matriz de características.

Comece por avaliar a qualidade da recuperação localmente. Crie um pequeno conjunto de avaliação — vinte ou trinta perguntas com respostas corretas conhecidas — e teste as opções de segmentação e incorporação com base nesse conjunto, utilizando uma implementação em memória. Isto demora um dia e determina mais sobre o seu resultado do que qualquer escolha subsequente.

Em seguida, conte os seus vetores. Se forem menos de cem mil, mantenha-os na memória. Se forem menos de alguns milhões e o Postgres já estiver a funcionar, utilize o pgvector. Acima desse valor, ou em caso de multilocação ou elevado volume de consultas, considere um sistema dedicado.

Em seguida, decida entre a versão gerida ou auto-hospedada. Opte pela versão gerida se preferir não gerir um índice distribuído e o custo for aceitável. Opte pela versão auto-hospedada se tiver requisitos de residência de dados, um volume previsível em grande escala ou competências de infraestrutura já existentes.

Em seguida, compare o custo com a sua carga de trabalho real, porque as unidades de faturação são incomparáveis e a intuição não serve de nada neste caso. A tarifação baseada em dimensões, a tarifação baseada em unidades e a tarifação baseada em recursos produzem resultados muito diferentes para a mesma aplicação.

E verifique o caminho de migração antes de se comprometer. Os vetores são portáteis — são apenas números —, mas as funcionalidades circundantes não o são. A sintaxe de filtragem de metadados, a configuração de pesquisa híbrida e os modelos de espaço de nomes diferem todos, pelo que o custo da migração reside no código da sua aplicação e não nos dados. Manter os documentos de origem e o pipeline de fragmentação faz com que qualquer migração futura seja uma reconstrução, em vez de uma exportação.

Perguntas frequentes

Qual é a melhor alternativa ao Pinecone?

Não existe uma resposta única, pois as categorias diferem. pgvector se já utilizar o Postgres e tiver alguns milhões de vetores ou menos. O Qdrant, se pretender uma base de dados vetorial simples e auto-hospedada. O Weaviate Cloud ou o Chroma Cloud, se preferir uma solução gerida e os respetivos modelos de preços se adequarem ao seu padrão de carga de trabalho.

Existe alguma alternativa gratuita ao Pinecone?

Várias. Todas as quatro principais bases de dados vetoriais de código aberto — Qdrant, Milvus, Chroma e Weaviate — têm licenças permissivas e são gratuitas para alojamento próprio. O pgvector é gratuito e funciona no Postgres que talvez já tenha. E, para menos de cerca de cem mil vetores, uma implementação NumPy na memória não custa absolutamente nada.

O pgvector é suficientemente bom para substituir uma base de dados vetorial?

Para uma grande maioria de aplicações, sim. Lida com milhões de vetores, mantém as suas incorporações na mesma transação e cópia de segurança que os seus dados relacionais e permite-lhe filtrar com junções SQL comuns. Não foi concebido para milhares de milhões de vetores e tem menos funcionalidades específicas de recuperação, sendo essa a área em que os sistemas dedicados ganham o seu lugar.

Qual é a base de dados vetorial mais económica?

Não é possível responder sem conhecer a sua carga de trabalho, porque as unidades de faturação diferem fundamentalmente — a Pinecone fatura por unidades de leitura e escrita, a Weaviate fatura por milhão de dimensões vetoriais, a Chroma fatura por GiB gravado e TiB consultado, e a Qdrant fatura pelos recursos provisionados. Faça as suas próprias simulações com cada calculadora.

Os bancos de dados vetoriais de código aberto estão prontos para produção?

O Qdrant, o Milvus, o Weaviate e o Chroma são todos desenvolvidos ativamente, têm licenças permissivas e são amplamente implementados em produção. A questão não é se funcionam, mas se pretende operá-los — que é precisamente o que as versões geridas de cada um oferecem.

Que licenças utilizam as bases de dados vetoriais de código aberto?

O Qdrant, o Milvus e o Chroma seguem a licença Apache-2.0; o núcleo do Weaviate segue a licença BSD de 3 cláusulas. Todas são permissivas, sem restrições de copyleft ou de âmbito de utilização, embora alguns fornecedores licenciem módulos empresariais específicos separadamente, o que vale a pena verificar se depender de algum deles.

Preciso de uma base de dados vetorial para RAG?

Não necessariamente. A qualidade da recuperação é determinada pela estratégia de fragmentação, pela escolha do modelo de incorporação e pela formulação da consulta, nenhum dos quais é melhorado por uma base de dados. Comece por construir e avaliar com uma implementação na memória; adicione infraestrutura quando o tamanho do corpus ou o volume de consultas o exigirem efetivamente.

Quão difícil é a migração entre bases de dados vetoriais?

Os vetores transferem-se facilmente — são matrizes de números. A dificuldade reside no código da sua aplicação, uma vez que a sintaxe de filtragem de metadados, a configuração da pesquisa híbrida e os modelos de multilocação diferem entre si. Manter os seus documentos de origem e o pipeline de segmentação faz com que a migração seja mais uma reconstrução do que uma exportação.

Conclusão

O mais importante a saber sobre esta categoria é que a escolha é entre quatro tipos de opções, e não entre cinco produtos. Serviços geridos, bases de dados auto-hospedadas, uma extensão da base de dados que já utiliza e nada de todo.

Para uma grande parte dos projetos, a resposta é uma das duas últimas opções. O pgvector processa milhões de vetores dentro da infraestrutura que já opera, com consistência transacional e junções SQL que nenhum serviço externo consegue oferecer. E para menos de cerca de cem mil vetores, uma multiplicação de matrizes na memória é exata, instantânea e gratuita.

Nos casos em que se justifica um sistema dedicado, as opções de código aberto têm todas licenças permissivas e são genuinamente adequadas para produção — Apache-2.0 para o Qdrant, Milvus e Chroma, BSD-3-Clause para o Weaviate — pelo que a auto-hospedagem é uma escolha real e não um compromisso. E quando pretender que seja gerido, avalie a sua própria carga de trabalho com base na calculadora de cada fornecedor, pois as unidades de faturação não são comparáveis e a mesma aplicação pode variar numa ordem de grandeza entre eles.

Seja qual for a sua escolha, faça primeiro o trabalho de avaliação da qualidade da recuperação e faça-o localmente. A base de dados raramente é o que torna um sistema de recuperação bom ou mau, e descobrir isso depois de assinar um contrato é a forma mais dispendiosa de o fazer.