Qdrant vs pgvector vs Supabase: qual escolher em 2026?

Aplicação de IA se divide entre servidor vetorial, banco relacional e plataforma backend

Navegue por tópicos

Para um produto que já usa PostgreSQL, pgvector costuma ser o começo mais simples. Escolha Supabase quando também precisar de uma plataforma com API e Auth. Escolha Qdrant quando a recuperação vetorial precisar evoluir como serviço próprio. Não decida por benchmark de outra máquina: dados, filtros, índice e operação mudam o resultado.

Um agente com RAG precisa recuperar contexto antes de responder. Isso não obriga você a adotar um banco vetorial dedicado.

A comparação real não é só Qdrant versus pgvector. Ela define se o produto vai operar uma base ou duas.

Chamamos esse custo adicional de Imposto da Segunda Base. Ele inclui deploy, acesso, monitoramento, backup e restauração de outro sistema.

Para Rafael, solo builder de micro-SaaS, essa conta pesa antes de qualquer promessa abstrata de performance. A escolha deve começar pela fonte de verdade dos dados.

Qdrant x pgvector x Supabase Vector: decisão rápida por cenário

💡 Vai rodar Qdrant numa VPS? A gente comparou o preço real em cada provedor — com renovação e requisitos — em VPS para Qdrant.

Critério Qdrant pgvector Supabase Vector
O que é Motor vetorial dedicado, com APIs REST e gRPC. Extensão de similaridade para PostgreSQL. pgvector no PostgreSQL da plataforma Supabase.
Fonte de verdade Coleção separada do banco transacional. Tabelas, relações e embeddings no mesmo PostgreSQL. PostgreSQL gerenciado ou plataforma auto-hospedada.
Deploy Serviço separado, inclusive em Docker. Extensão no PostgreSQL do produto. Cloud gerenciada ou stack Docker Compose.
Segurança Chaves, JWT, binding de rede e TLS documentados. Controles de acesso já definidos para PostgreSQL. Controles da plataforma e do PostgreSQL.
Backup Snapshots exigem cópia externa e teste de restauração. Ferramentas nativas, incluindo point-in-time recovery. Varia entre o serviço gerenciado e a stack própria.
Escala Shards e réplicas entre peers, com mais operação. Índices HNSW e IVFFlat no banco relacional. Índices HNSW e IVFFlat no PostgreSQL da plataforma.
Custo operacional Outra base para proteger, monitorar e recuperar. Menos serviços quando PostgreSQL já é central. Menos setup inicial; a plataforma amplia a operação própria.
Melhor encaixe Busca que exige evolução independente. Produto PostgreSQL-first com joins e permissões. Produto que também quer Auth, API, Realtime ou Storage.
Quando evitar Quando a segunda operação não resolve uma dor concreta. Quando a recuperação precisa se isolar da carga relacional. Quando você só quer pgvector, sem a plataforma inteira.

A tabela não mede qual é mais rápido. Ela mostra quem assume cada responsabilidade.

O que você está escolhendo de verdade: uma ou duas bases?

Embeddings não vivem sozinhos. Um RAG normalmente também lida com usuários, permissões, documentos, histórico e regras de negócio.

Se tudo isso já está no PostgreSQL, pgvector mantém a busca perto dos joins e das transações. O PostgreSQL oferece ACID, JOINs e point-in-time recovery, segundo a documentação oficial do pgvector e a documentação de backup do PostgreSQL.

Ao usar Qdrant, você ganha um serviço especializado. Também passa a decidir como sincroniza documentos, metadados e exclusões entre sistemas.

Isso não torna Qdrant uma escolha ruim. Só deixa explícito o Imposto da Segunda Base.

Supabase fica entre esses caminhos. Ele usa pgvector no PostgreSQL, mas acrescenta uma plataforma em volta dele. API, Auth, Realtime e Storage podem reduzir trabalho inicial para quem precisa desses blocos.

Se o seu produto já usa Supabase, vale entender como manter o PostgreSQL como base central. Veja também nossa análise sobre como preservar uma arquitetura PostgreSQL-first no Supabase.

Qdrant: quando um banco vetorial dedicado paga o Imposto da Segunda Base

Qdrant é um mecanismo open source de busca vetorial. O projeto documenta APIs REST e gRPC, filtros de payload, quantização, implantação distribuída e GPU opcional para indexação.

GPU opcional não significa GPU obrigatória para consultar vetores. Essa distinção evita superdimensionar a VPS antes de medir a carga.

A opção faz sentido quando a recuperação vetorial deixou de ser um detalhe de tabela. Ela precisa de isolamento, recursos próprios ou crescimento independente do banco relacional.

Filtros, coleções, quantização e escala

Qdrant organiza dados em coleções e permite filtrar payloads durante a busca. Também documenta quantização e distribuição entre peers com shards e réplicas.

Esses recursos importam quando a arquitetura pede disponibilidade ou capacidade adicionais. Eles não são um motivo automático para criar um cluster em um micro-SaaS.

O planejamento de capacidade do Qdrant depende de vetores, dimensão, tipo de dado, quantização, payload, índices, réplicas e armazenamento. A própria documentação de planejamento de capacidade do Qdrant não oferece uma RAM universal de VPS.

Existe um exemplo oficial usado como referência para vetores de 1.024 dimensões. Mesmo assim, ele não inclui automaticamente payload, réplicas ou os outros contêineres da aplicação.

Por isso, “tenho X vetores, então preciso de Y GB” é uma simplificação perigosa. Meça o corpus real, a dimensão do embedding, os filtros e o uso de disco.

Docker, volumes, snapshots e chaves de API

Self-hosted dá controle sobre o processo e o ambiente. Em troca, volumes persistentes, atualizações e recuperação passam a ser uma responsabilidade explícita.

Qdrant suporta snapshots de coleções para backup, recuperação e migração, conforme a documentação de snapshots. Snapshot não substitui cópia externa, retenção definida e teste de restauração.

A documentação também cobre chave administrativa, chave somente leitura, JWT, binding de rede e TLS. Não exponha a API vetorial publicamente sem autenticação, rede restrita e HTTPS adequados.

Checklist antes de criar uma segunda base

  1. Corpus: quantos documentos e vetores existem hoje, e como crescem?
  2. Dimensão: qual modelo de embedding será usado e qual dimensão ele produz?
  3. Filtros: as consultas precisam respeitar tenant, usuário, documento ou permissão?
  4. Índice: qual recall esperado é aceitável para a experiência do produto?
  5. Backup: você consegue restaurar uma coleção e validar o resultado?
  6. Métricas: você mede latência, falhas, disco, RAM e qualidade da recuperação?
  7. Operação: quem atualiza, protege e investiga esse segundo serviço?

Se as respostas ainda são vagas, comece com menos fronteiras. Você pode extrair a busca para Qdrant quando houver uma necessidade mensurável.

pgvector: quando a busca deve ficar no PostgreSQL

pgvector é uma extensão open source para busca por similaridade no PostgreSQL. Ela suporta busca exata e aproximada, vetores single, half, binary e sparse, além de métricas e índices HNSW ou IVFFlat.

Para um micro-SaaS que já depende de PostgreSQL, esse desenho reduz serviços. Usuários, permissões, documentos e embeddings podem permanecer no mesmo ecossistema.

Não trate isso como limitação de protótipo. A decisão é arquitetural, não um rótulo de maturidade.

Joins, ACID, backup e menor superfície operacional

Quando uma consulta de RAG precisa combinar similaridade com dados relacionais, estar no PostgreSQL pode simplificar o caminho. Você aproveita clientes, ORM, observabilidade e rotina de backup que já existem.

Essa simplicidade tem valor operacional. Há menos segredos, endpoints, volumes e procedimentos de recuperação para acompanhar.

Ela não elimina a necessidade de teste. Um índice vetorial muda consumo de memória, disco e comportamento das consultas.

HNSW, IVFFlat e o cuidado com filtros ANN

Segundo o projeto pgvector, HNSW oferece melhor trade-off entre velocidade e recall do que IVFFlat. Porém, usa mais memória e tende a construir mais lentamente. IVFFlat exige uma etapa de treinamento.

Nenhuma dessas características prova que pgvector vence ou perde para Qdrant. Elas descrevem trade-offs dentro da extensão.

Há outro ponto importante para RAG multiusuário. Com índice aproximado e filtro em outra coluna, a consulta pode receber o filtro depois do scan. Nesse caso, pode retornar menos linhas do que o solicitado.

A documentação do pgvector no Supabase orienta busca iterativa para procurar mais entradas até achar resultados suficientes. Teste consultas com filtros reais de tenant e permissão.

Supabase Vector: quando você também precisa da plataforma

Supabase Vector não é um terceiro motor separado de pgvector. É a capacidade vetorial do PostgreSQL dentro da plataforma Supabase.

Essa separação conceitual ajuda a comparar corretamente. Você pode escolher pgvector por SQL. Ou pode escolher Supabase porque quer, junto, API, Auth, Realtime, Storage e ferramentas de desenvolvimento.

Supabase gera API REST a partir do schema e oferece bibliotecas para REST e Realtime. Também disponibiliza uma API GraphQL gerada a partir do PostgreSQL, conforme sua documentação de APIs.

Cloud gerenciado versus Docker Compose próprio

No serviço gerenciado, o Supabase reduz trabalho de infraestrutura inicial. Em 29 de agosto de 2026, o plano Free declarava 500 MB de banco e 500 MB de RAM compartilhada. O Pro partia de US$25 por mês, com o primeiro projeto, 8 GB de disco e backups diários com retenção de sete dias.

Esses valores estão em dólar, podem mudar e não incluem toda configuração de compute. Consulte a página de preços do Supabase antes de decidir.

No self-hosting, Supabase usa Docker Compose. A documentação pede Linux, Git, Docker, Compose e redes. Para todos os componentes, ela informa mínimo de 4 GB de RAM, 2 CPUs e 40 GB de SSD. Para desenvolvimento e pequenas ou médias produções, recomenda 8 GB ou mais, 4 cores ou mais e 80 GB ou mais de SSD.

Esses requisitos são da plataforma completa. Eles não são requisito de pgvector isolado nem devem ser comparados diretamente com um contêiner Qdrant.

A documentação de self-hosting do Supabase explica o tamanho operacional dessa escolha. Auto-hospedar a plataforma inteira pode custar menos em licença, mas amplia a superfície de manutenção.

Custo real: licença não é custo operacional

Qdrant open source não cobra licença para auto-hospedagem. Qdrant Cloud tinha Community gratuito e Managed Cloud a partir de US$25 em 29 de agosto de 2026, segundo a página de preços do Qdrant.

Esse número não responde quanto sua operação custa. Não inclui necessariamente embeddings, banco relacional, armazenamento, backups, observabilidade ou tempo de manutenção.

O custo relevante para Rafael é previsibilidade. Uma VPS pode reunir contêineres e dados sob seu controle, mas só é econômica quando existe disciplina operacional.

Não use preço de VPS como regra de dimensionamento. A pesquisa não encontrou um valor atual verificável para esse cenário no Brasil. Compare a configuração necessária, a localização da aplicação e a responsabilidade que você aceita operar.

Escolha por cenário: micro-SaaS, RAG multiusuário e busca em crescimento

Use pgvector se:

  • seu produto já usa PostgreSQL como fonte de verdade;
  • joins, transações e permissões fazem parte de quase toda consulta;
  • você quer reduzir serviços, backups e superfícies de acesso;
  • a busca vetorial ainda não exige operação independente comprovada.

Use Supabase Vector se:

  • você quer pgvector, mas também precisa de Auth, API, Realtime ou Storage;
  • o serviço gerenciado reduz seu tempo até a primeira versão;
  • você entende que plataforma e extensão são escolhas diferentes;
  • os limites do plano e o custo em dólar cabem no seu cenário.

Use Qdrant se:

  • a recuperação vetorial precisa de um serviço especializado;
  • filtros, coleções, quantização ou evolução independente resolvem uma dor medida;
  • você aceita operar persistência, snapshots, acesso e monitoramento próprios;
  • a carga vetorial não deve disputar o mesmo banco relacional sem uma razão clara.

Para RAG multiusuário, não escolha antes de testar filtros de tenant. Para busca em crescimento, não escolha por número fixo de vetores. Corpus, índice, dimensão, cache e concorrência mudam a necessidade.

Checklist antes de subir em uma VPS

  1. Defina o corpus que será indexado e a frequência de atualização.
  2. Registre a dimensão e o modelo de embedding escolhido.
  3. Rode consultas representativas, com e sem filtros de permissão.
  4. Avalie a qualidade da recuperação, não apenas o tempo da consulta.
  5. Meça RAM, disco e crescimento dos índices no corpus real.
  6. Crie uma rotina de cópia externa para dados e snapshots.
  7. Execute uma restauração de teste antes de depender do RAG em produção.
  8. Restrinja portas, chaves e acesso de rede ao banco vetorial.
  9. Separe o orçamento de infraestrutura do custo de embeddings e LLM.
  10. Documente quem atualiza os contêineres e responde por incidentes.

Se a conclusão for self-hosting, priorize uma VPS que suporte Docker, volumes persistentes e uma rotina de backup que você realmente consiga operar. Conheça a oferta de VPS da Servla no Runzos para avaliar essa rota de infraestrutura.

FAQ: dúvidas sobre Qdrant, pgvector e Supabase Vector

Qdrant é melhor que pgvector?

Não existe vencedor universal. Qdrant é um serviço vetorial dedicado, com recursos próprios de coleções, filtros, quantização e distribuição. pgvector mantém a busca dentro do PostgreSQL, junto de ACID, joins e rotinas de backup do banco. Comece pela fonte de verdade, pelos filtros e pela capacidade de operação. Só um teste com corpus, consultas e metas de qualidade reais indica se a separação vale o custo.

Supabase Vector é diferente de pgvector?

Sim, mas eles não competem como dois motores vetoriais independentes. pgvector é a extensão de busca por similaridade no PostgreSQL. Supabase é uma plataforma que inclui PostgreSQL e pode usar pgvector, além de serviços como API, Auth, Realtime e Storage. Você escolhe Supabase quando esses componentes também agregam valor, não porque ele tenha um motor vetorial separado.

Quanta RAM preciso para Qdrant?

Não há uma resposta universal. O planejamento depende do número de vetores, da dimensão, do payload, do índice, da quantização, das réplicas e do armazenamento. A documentação do Qdrant oferece fórmulas e exemplos, mas eles não substituem medição. Suba um corpus representativo, execute suas consultas e acompanhe RAM, disco e qualidade da recuperação antes de fechar a configuração de produção.

Posso rodar Supabase e pgvector em uma VPS?

Sim. A documentação do Supabase usa Docker Compose para self-hosting. Ela informa mínimo de 4 GB de RAM, 2 CPUs e 40 GB de SSD para todos os componentes, com recomendação maior para desenvolvimento e pequenas ou médias produções. Esses números pertencem à plataforma completa. Se você precisa apenas de PostgreSQL com pgvector, avalie se operar todo o conjunto Supabase é necessário.

Quando não devo criar um banco vetorial separado?

Não crie uma segunda base quando o produto já é PostgreSQL-first, a busca ainda é parte pequena do fluxo e você não mediu uma necessidade de isolamento. Nesse cenário, pgvector pode manter dados, permissões, joins e recuperação na mesma operação. Qdrant passa a fazer sentido quando a recuperação exige recursos especializados ou evolução independente que justifique backup, segurança e observabilidade adicionais.

Conclusão: comece pela operação que seu produto sustenta

Qdrant, pgvector e Supabase Vector resolvem problemas próximos com fronteiras operacionais diferentes. pgvector reduz a complexidade para produtos PostgreSQL-first. Supabase encurta o caminho quando a plataforma também é necessária. Qdrant entra quando a busca vetorial merece ser tratada como serviço próprio.

A recomendação mais honesta é pequena: teste com seu corpus, seus filtros e sua meta de qualidade. Depois escolha a infraestrutura que você consegue proteger, fazer backup e restaurar sem improviso.

Se essa decisão levar seu RAG para Docker e VPS própria, compare também a oferta de VPS da Hostinger no Runzos. O melhor banco vetorial perde valor se a operação ao redor dele não for sustentável.

Foto de Maicon Ramos

Maicon Ramos

Infoprodutor e especialista em automações de Marketing, fundador do Automação sem Limites, uma comunidade para ajudar empreendedores e startup.