Como escolher um VPS para bancos de dados vetoriais RAG (2026): configuração e custos de Qdrant, pgvector e Milvus

Se você só precisa de um armazenamento vetorial para o Dify, o AnythingLLM ou seu próprio aplicativo RAG, eu escolheria primeiro entre pgvector e Qdrant. O Milvus não é ruim, mas "pode ficar muito grande no futuro" não é motivo suficiente para implantar agora um sistema distribuído.

O site já tem um tutorial completo de implantação de RAG privado com Dify e um tutorial de base de conhecimento privada com AnythingLLM. Este artigo resolve apenas a camada abaixo deles: como os vetores são realmente armazenados, como comprar a máquina e como executar o serviço com segurança.

"Quantas memórias 1 milhão de vetores precisam" não tem resposta universal independente do modelo. É preciso saber pelo menos:

• Quantas dimensões os vetores têm;
• Se usa float32, meia precisão ou dados quantizados;
• Se usa busca exata, HNSW ou IVFFlat;
• Quanto texto, rótulos e payload de negócio cada registro também carrega;
• Se há réplicas, WAL, snapshots e consultas concorrentes;
• Quanta memória de trabalho a construção do índice precisa.

Tomando como exemplo vetores brutos float32, faça primeiro uma estimativa mínima:

原始向量字节数 ≈ 向量数量 × 维度 × 4

O README oficial do pgvector é mais preciso: vector ocupa 4 × dimensions + 8 bytes por entrada. Supondo 1536 dimensões:

10 万条：100000 × (4 × 1536 + 8) ≈ 587 MiB
100 万条：1000000 × (4 × 1536 + 8) ≈ 5.73 GiB

Isso é apenas o vetor em si, sem contar a sobrecarga de linha do PostgreSQL, o grafo HNSW, o payload, a memória de construção do índice, o cache e o sistema operacional. Chegando aqui dá para entender: um VPS de 4 GB pode fazer validação funcional, mas você não pode prometer que ele armazenará de forma estável 1 milhão de entradas HNSW de 1536 dimensões só porque "os vetores brutos ocupam apenas alguns GB".

Se o modelo gera 768 dimensões, os dados brutos caem aproximadamente pela metade; trocar para meia precisão também pode reduzir o conjunto de trabalho, mas traz compromissos de precisão e implementação. Calcule primeiro o volume bruto com suas próprias dimensões de embedding e depois deixe margem para índices, campos de negócio, backups e crescimento; isso é mais confiável do que copiar a "tabela de capacidade" de outra pessoa.

O pgvector é uma extensão do PostgreSQL. A vantagem não é "ser sempre o mais rápido", mas poder colocar vetores e dados relacionais como usuários, documentos, permissões e pedidos no mesmo sistema de transações e backups.

O README oficial atual oferece suporte a busca exata de vizinhos mais próximos e também a dois índices aproximados, HNSW e IVFFlat. O HNSW costuma oferecer melhor equilíbrio entre velocidade e recall, mas é construído mais lentamente e usa mais memória; o IVFFlat é construído de forma mais leve, mas seus parâmetros e a distribuição dos dados afetam mais o recall.

Casos em que o pgvector se encaixa bem:

• Você já tem um PostgreSQL estável;
• A busca vetorial precisa ser filtrada junto com muitas condições relacionais;
• A escala de dados é temporariamente pequena e a equipe não quer manter outro banco de dados;
• Você precisa de transações, JOIN, WAL, PITR e das ferramentas de monitoramento existentes do PostgreSQL.

As armadilhas também são diretas: consultas de negócio, autovacuum, backups e construção do índice HNSW disputam os recursos do mesmo banco de dados. A documentação oficial também alerta que o grafo HNSW é construído mais rapidamente quando cabe em maintenance_work_mem, mas definir esse valor alto demais pode esgotar a memória do servidor.

Quando uma equipe pequena já tem PostgreSQL, o pgvector costuma ser o primeiro passo de menor custo; quando a busca vetorial realmente se tornar uma carga independente, separá-la para o Qdrant será mais fácil do que manter três ou quatro conjuntos de componentes desde o início.

O Qdrant oferece interfaces REST e gRPC independentes, com vetores, payload e filtragem projetados em torno de cenários de busca. Para bases de conhecimento RAG, seu limite é mais claro do que "colocar mais uma extensão no banco de dados de negócio": se o aplicativo falhar, não necessariamente derruba o banco vetorial, e escalar o banco vetorial não exige mexer primeiro no banco de dados principal de negócio.

O Qdrant se encaixa nestes casos:

• Vários aplicativos compartilham um serviço vetorial;
• A filtragem por payload faz parte da cadeia de busca;
• Você quer uma API independente para gerenciar coleções, pontos e snapshots;
• Talvez mais adiante queira ampliar memória, disco ou separar nós.

O custo é que você mesmo precisa cuidar de API Key, TLS, snapshots, atualizações e monitoramento. A versão auto-hospedada do Qdrant não fica segura automaticamente após a instalação, e a porta 6333 não deve ser exposta diretamente à internet.

O Milvus tem modos de implantação como Lite, Standalone e Distributed. O Standalone pode rodar em uma única máquina; o Distributed é voltado a cenários de grande escala que superam a capacidade de uma única máquina, com complexidade de componentes e operações significativamente maior.

Nas recomendações oficiais atuais de hardware do Milvus, o Standalone exige no mínimo 8 GB e recomenda 16 GB de memória; o Cluster exige no mínimo 32 GB e recomenda 128 GB, e o disco deve ser no mínimo SATA SSD, com NVMe recomendado. Esses números já mostram que o Milvus não é um substituto equivalente em um VPS pequeno de 2 núcleos 4 GB.

Quando vale a pena considerá-lo?

• Os recursos de uma única máquina já foram confirmados como gargalo por monitoramento;
• A escala de dados, as gravações e o volume de consultas continuam crescendo;
• A equipe consegue manter armazenamento de objetos, monitoramento, backups e atualizações de vários componentes;
• Os benefícios da distribuição superam os custos extras de máquinas e mão de obra.

Se o projeto está apenas começando e você só se preocupa com "ter 100 milhões de entradas no futuro", primeiro registre o crescimento dos dados, a concorrência de consultas e as metas de latência. Sem esses dados, a distribuição é apenas pagar o imposto operacional antecipadamente.

As faixas iniciais abaixo são conservadoras, não garantias de capacidade. Dimensões, parâmetros de índice, payload, concorrência e plataformas de CPU diferentes farão os resultados variarem muito.

Não declare que a máquina é suficiente só porque as consultas funcionam em uma coleção vazia. O que realmente enche a memória e o disco é a importação em lote, a construção de índices, as consultas filtradas e os snapshots acontecendo ao mesmo tempo.

Prepare um lote de dados que represente o negócio real: não simplifique de forma leviana as dimensões vetoriais, o comprimento do texto, o número de rótulos nem as condições de filtragem. Primeiro registre o tamanho do diretório de dados e a memória do processo sem índices, depois crie o índice HNSW ou IVFFlat com o qual pretende lançar e compare disco, picos de memória e tempo de construção antes e depois da indexação.

Em seguida, reproduza consultas reais: inclua não só a busca normal de vizinhos mais próximos, mas também os filtros de inquilino, permissões, tempo e categoria que o negócio usará. Testar apenas a latência média de uma única requisição tem pouco sentido; no mínimo observe ao mesmo tempo a concorrência no pico, a latência P95/P99, a taxa de erros e as mudanças de recall.

Por fim, faça um simulado de falha: crie um snapshot, transfira a cópia para outro lugar, exclua a coleção de teste e restaure conforme a documentação. Se o tempo de recuperação já ultrapassa a janela de inatividade que o negócio pode aceitar, mesmo que as consultas diárias sejam rápidas, essa configuração não pode ser considerada aprovada.

Registre em cada rodada o número de vetores, dimensões, parâmetros de índice, uso de disco, picos de memória e resultados das consultas. Repita uma vez quando os dados dobrarem; isso ajuda mais a decidir se deve adicionar memória, trocar discos ou separar em um serviço independente do que copiar os benchmarks de outras pessoas.

As prioridades de compra comuns para busca vetorial são:

1. Margem de memória: a construção de índices e as consultas precisam de conjuntos de trabalho; operar a longo prazo a 95% de memória é perigoso.
2. I/O aleatório SSD/NVMe: dados, WAL, snapshots e índices leem e gravam no disco; olhar só a capacidade e não a latência leva facilmente a problemas.
3. Modelo de CPU: construir índices e calcular distâncias consome CPU; um multinúcleo compartilhado antigo não é necessariamente mais rápido que uma plataforma nova com menos núcleos.
4. Saída de backup: os snapshots precisam ser transferidos para outra máquina ou armazenamento de objetos; o tráfego de saída e a velocidade afetam o tempo de recuperação.
5. Localização do data center: mantenha o banco vetorial o mais próximo possível do aplicativo que o chama; não faça cada busca cruzar continentes.

Também não calcule só o VPS no custo mensal:

真实月成本 = VPS + 异地备份/对象存储 + 快照空间 + 出站流量 + 维护时间

O pgvector pode economizar um serviço, mas concentra o risco no banco de dados principal; o Qdrant adiciona um contêiner, mas com limites claros; o Milvus Distributed pode escalar horizontalmente, mas também eleva ao mesmo tempo o número de máquinas e o custo operacional.

O que segue pressupõe Ubuntu/Debian, Docker Compose já instalado e Caddy instalado no host. O exemplo fixa o Qdrant v1.18.3, lançado em 17 de julho de 2026; não use latest a longo prazo em produção.

Criar diretórios:

sudo mkdir -p /opt/qdrant/{storage,snapshots}
sudo chown -R "$USER":"$USER" /opt/qdrant
cd /opt/qdrant

Gerar uma API Key e restringir as permissões de .env:

umask 077
printf 'QDRANT_API_KEY=%s\n' "$(openssl rand -hex 32)" > .env

Criar compose.yaml:

services:
  qdrant:
    image: qdrant/qdrant:v1.18.3
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "127.0.0.1:6333:6333"
    environment:
      QDRANT__SERVICE__API_KEY: "${QDRANT_API_KEY}"
    volumes:
      - ./storage:/qdrant/storage
      - ./snapshots:/qdrant/snapshots

Aqui a 6333 é deliberadamente vinculada a 127.0.0.1. Não é possível acessá-la diretamente de fora; apenas pelo Caddy no host. Se você não usa gRPC, não precisa expor a 6334.

Iniciar e verificar:

docker compose pull
docker compose up -d
docker compose ps

set -a
. ./.env
set +a
curl -fsS -H "api-key: ${QDRANT_API_KEY}" http://127.0.0.1:6333/collections

Se retornar a lista de coleções, o contêiner e a autenticação estão funcionando. Se retornar 401, confirme primeiro que .env está carregado, que a variável de ambiente do contêiner existe e verifique docker compose logs qdrant.

Primeiro aponte os registros A/AAAA de vector.example.com para o VPS e garanta que o firewall só abra SSH, 80 e 443. 6333/tcp não precisa de exposição pública.

Caddyfile do host:

vector.example.com {
    reverse_proxy 127.0.0.1:6333
}

Verificar e carregar:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

O Caddy solicitará e renovará certificados para um domínio válido. Os clientes ainda devem incluir o cabeçalho de requisição api-key do Qdrant ao acessar:

curl -fsS \
  -H "api-key: ${QDRANT_API_KEY}" \
  https://vector.example.com/collections

Substitua vector.example.com pelo seu próprio domínio. Não escreva a API Key no Caddyfile, no repositório Git nem no JavaScript do frontend; ela deve ser guardada em variáveis de ambiente do servidor ou em um sistema de gerenciamento de segredos.

Supondo que a coleção se chame docs, crie um snapshot:

curl -fsS -X POST \
  -H "api-key: ${QDRANT_API_KEY}" \
  http://127.0.0.1:6333/collections/docs/snapshots

Listar os snapshots existentes:

curl -fsS \
  -H "api-key: ${QDRANT_API_KEY}" \
  http://127.0.0.1:6333/collections/docs/snapshots

O arquivo de snapshot continua no diretório /opt/qdrant/snapshots do host. Se o disco da máquina falhar, os snapshots no mesmo disco também podem ser perdidos, então copie-os periodicamente para armazenamento de objetos ou para outro provedor de nuvem.

Antes de restaurar, leia a documentação do Qdrant Snapshot correspondente à versão atual e valide em uma coleção de teste. A forma da API para enviar um snapshot local é a seguinte:

curl -fsS -X POST \
  -H "api-key: ${QDRANT_API_KEY}" \
  -F "snapshot=@/path/to/docs.snapshot" \
  "http://127.0.0.1:6333/collections/docs/snapshots/upload?priority=snapshot"

/path/to/docs.snapshot é o caminho real do arquivo que você recuperou do backup externo. A restauração afeta a coleção de destino; não teste pela primeira vez no banco de dados de produção.

Snapshots, imagens e backups de máquina inteira não são a mesma coisa; você pode projetar o processo de recuperação consultando as diferenças entre snapshots, backups e imagens de VPS.

Uma atualização de produção deve fazer pelo menos estas etapas:

1. Ler as release notes e as notas de compatibilidade da versão de destino;
2. Criar um snapshot da coleção e copiá-lo para fora do site;
3. Registrar a versão atual da imagem e o arquivo compose;
4. Alterar a tag da imagem para uma versão explícita antes de fazer pull;
5. Após iniciar, verificar a saúde, o número de coleções e as consultas de negócio;
6. Manter a configuração antiga e os backups que permitam reverter.

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 qdrant

Atualizações de banco de dados são diferentes de contêineres web comuns. Formatos de dados, reconstrução de índices e tempo de recuperação precisam ser validados antecipadamente; você não pode considerar a atualização bem-sucedida só porque o contêiner está running.

Observe primeiro de forma contínua durante os picos de negócio, não apenas um único top:

# 容器 CPU、内存和网络
docker stats qdrant

# 磁盘空间和 inode
df -h /opt/qdrant
df -i /opt/qdrant

# Qdrant 日志
docker compose logs --since=1h qdrant

# 本地健康检查
curl -fsS http://127.0.0.1:6333/healthz

# Prometheus 格式指标，需要 API Key 时保留请求头
curl -fsS -H "api-key: ${QDRANT_API_KEY}" http://127.0.0.1:6333/metrics

Estes sinais indicam que é hora de ampliar ou separar:

• A memória normal se aproxima do limite, começa o swapping contínuo ou ocorrem OOM;
• As consultas de negócio estouram claramente o tempo limite durante a construção de índices;
• O espaço livre em disco não basta para guardar ao mesmo tempo dados, WAL e snapshots;
• A latência de I/O aleatório continua subindo;
• A janela de backup fica cada vez mais longa e os simulados de recuperação não são concluídos no tempo alvo;
• O preço da ampliação vertical de uma única máquina já se aproxima de opções multinó ou gerenciadas.

Não olhe só o número de vetores. Faça testes de carga com embeddings reais, condições de filtragem reais e níveis de concorrência, registre a latência P95/P99, as mudanças de recall, os picos de memória e o tempo de construção de índices, e então decida se deve adicionar memória, trocar para NVMe, fazer quantização ou separar serviços.

Se o projeto já está no PostgreSQL e a escala vetorial ainda é pequena, comece com pgvector; se quiser oferecer uma interface independente para vários aplicativos RAG, o Qdrant de 4 núcleos 8 GB é um ponto de partida mais fácil de gerenciar; se tiver certeza de que precisa de mais recursos em uma única máquina, avalie 8 núcleos 16 GB+ e Milvus Standalone; só depois que os gargalos de uma única máquina forem confirmados, fale em Milvus Distributed.

Ao comprar um VPS, não aperte demais a memória só para economizar um pouco na mensalidade. O que um banco de dados vetorial mais teme não é a carga média, mas a construção de índices, a importação em lote, os snapshots e as consultas de negócio coincidindo ao mesmo tempo. Deixar margem, trazer a 6333 de volta para o localhost e copiar os snapshots para fora é mais útil do que perseguir uma tabela de benchmarks desconectada do seu conjunto de dados.

• Qdrant Quickstart
• Qdrant Security
• Qdrant Snapshots
• Qdrant Monitoring
• README oficial do pgvector
• Modos de instalação e implantação do Milvus
• Pré-requisitos do Milvus Docker
• Caddy reverse_proxy