pgvector ou Qdrant — qual devo auto-hospedar?

Se você já roda Postgres (ou quer um banco de dados para os dados do app e os embeddings juntos), o pgvector é a escolha de menor esforço — é só uma extensão. Se você tem milhões de vetores ou quer um motor feito sob medida com filtragem rápida, o Qdrant vale o serviço separado. Para a maioria dos agentes começando, pgvector no Postgres é bastante.

Quanta RAM um banco vetorial precisa?

Mais do que você imagina, porque uma boa busca quer o índice em memória. Regra aproximada: algumas centenas de milhares de embeddings cabem confortavelmente em 2 GB; ao chegar aos poucos milhões, planeje 4 GB+ e ajuste o índice. Comece em 2 GB, observe a memória, redimensione quando a busca ficar lenta.

Por que auto-hospedar um vector store em vez de um gerenciado?

Duas razões pelas quais as pessoas de fato fazem isso: seus embeddings frequentemente contêm seus dados privados (notas, docs, conteúdo de clientes), e um store auto-hospedado mantém isso num servidor que você controla. E é de custo fixo — um serviço vetorial gerenciado cobra por vetores e consultas, enquanto um VPS é um número mensal sem medidor por consulta.

Um banco vetorial e meu agente podem rodar no mesmo VPS?

Sim, para cargas pequenas a médias — co-localizar o agente e uma instância pgvector/Qdrant numa máquina é simples e corta a latência para quase zero. Divida-os em servidores separados só quando um começar a deixar o outro sem RAM, o que é um bom problema para depois, não uma preocupação do primeiro dia.

Os embeddings ocupam muito disco?

Um único embedding tem alguns kilobytes, então um milhão deles são alguns gigabytes mais a sobrecarga do índice — significativo, mas não enorme. 25–45 GB de disco cobrem um store de memória substancial para a maioria dos agentes. RAM, não disco, é geralmente o primeiro limite que você atinge.

Hospede um banco de dados vetorial para a memória de agentes de IA num VPS

Um agente de IA sem memória fica preso se reapresentando a cada conversa. A solução é um banco de dados vetorial — ele armazena embeddings dos seus documentos, notas ou conversas passadas para que o agente possa relembrar as partes relevantes sob demanda (é o "R" de RAG). Você pode alugar isso como um serviço gerenciado, ou pode rodá-lo você mesmo num VPS e manter seus dados — que frequentemente são seus dados privados — numa máquina que você controla. Eis como, e o que isso de fato custa em RAM.

Duas boas opções

Você não precisa de nada exótico. Dois caminhos cobrem quase todo mundo:

pgvector — uma extensão do Postgres. Se você já roda Postgres (ou está feliz em rodar), isto adiciona busca vetorial ao banco de dados que você já tem. Um serviço, um backup, SQL que você conhece. O começo de menor esforço por larga margem.

Qdrant — um motor vetorial feito sob medida. Recorra a ele quando você tem muitos vetores (poucos milhões+) ou quer filtragem rápida por metadados e uma API dedicada. É um serviço separado para rodar, mas é feito para exatamente este trabalho.

Para a maioria dos agentes se firmando, o pgvector é a primeira resposta certa. Mude para o Qdrant quando você tiver ultrapassado, não antes.

A realidade da RAM (esta é a parte que as pessoas subestimam)

A busca vetorial é rápida porque o índice mora em memória — então RAM, não disco, é a sua real restrição. Um guia aproximado:

Algumas centenas de milhares de embeddings — confortável em 2 GB.
Poucos milhões — planeje 4 GB+ e ajuste o índice.
O disco é a parte fácil: um milhão de embeddings são só alguns GB, então 25–45 GB cobrem um store sério.

Então dimensione para o índice, não para o arquivo. (Mesma lógica do guia geral de dimensionamento — a coisa pesada não é óbvia até você medir.)

Início rápido: pgvector

Numa máquina com Postgres (Docker é o mais fácil — mesmo padrão de auto-hospedar o n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- combine com as dimensões do seu modelo de embedding
);

-- depois de ter dados, construa um índice para busca rápida:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Seu agente insere content + o embedding dele, depois consulta com ORDER BY embedding <=> $query_embedding LIMIT 5 para puxar as memórias mais próximas. É esse o ciclo inteiro.

Prefere Qdrant? É um único container Docker expondo uma API HTTP/gRPC; você cria uma collection com o seu tamanho de vetor e faz upsert de pontos. Mesma ideia, motor dedicado.

Ele pode compartilhar a máquina com o agente?

Sim — para stores de memória pequenos a médios, rode o banco vetorial no mesmo VPS que o agente. É mais simples e a latência é basicamente zero. Divida-os em servidores separados só quando um começar a espremer o outro para fora da RAM. Essa é uma decisão para depois, de bom-problema-para-ter, não uma do primeiro dia.

Ressalvas honestas

A RAM é a parede, e é silenciosa. A busca fica rápida até o índice não caber mais em memória, então degrada. Observe a memória e redimensione antes de ela morder — não espere consultas lentas te avisarem.
Embeddings custam tokens para criar. Todo documento que você faz embedding é uma chamada de API a um modelo de embedding. O store é barato de hospedar; gerar os vetores é o custo recorrente — relevante para o que rodar um agente de fato custa.
Faça backup. A memória do seu agente é dado como qualquer outro. Se importa, tire um snapshot.

Dentro disso, um vector store auto-hospedado é uma forma limpa de dar a um agente memória durável sem entregar seus dados privados a um terceiro. Comece com pgvector numa máquina de 2 GB, fique de olho na RAM e cresça para o Qdrant ou um plano maior só quando os números te disserem.