How to Choose a VPS for RAG Vector Databases (2026): Qdrant, pgvector, and Milvus Configuration and Cost Comparison

If you just need a vector store for Dify, AnythingLLM, or your own RAG application, I would choose between pgvector and Qdrant first. Milvus is fine, but "it might be very large later" is not sufficient reason to deploy a distributed system now.

The site already has a complete Dify private RAG deployment tutorial and an AnythingLLM private knowledge base tutorial. This article only addresses the layer beneath them: how vectors are actually stored, how to buy the machine, and how to run the service securely.

"How much memory do 1 million vectors need" has no universal answer independent of the model. You need to know at least:

• How many dimensions the vectors have;
• Whether using float32, half precision, or quantized data;
• Whether using exact search, HNSW, or IVFFlat;
• How much text, tags, and business payload each record also carries;
• Whether there are replicas, WAL, snapshots, and concurrent queries;
• How much working memory index building needs.

Taking float32 raw vectors as an example, start with a minimal estimate:

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

The official pgvector README is more precise: vector occupies 4 × dimensions + 8 bytes per entry. Assuming 1536 dimensions:

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

This is only the vectors themselves, not including PostgreSQL row overhead, HNSW graphs, payload, index build memory, cache, and the operating system. By this point you can see: a 4GB VPS can do functional validation, but you cannot promise it will stably hold 1 million 1536-dimensional HNSW entries just because "the raw vectors are only a few GB."

If the model outputs 768 dimensions, the raw data is roughly halved; switching to half precision can also shrink the working set, but brings trade-offs in precision and implementation. Calculate the raw volume with your own embedding dimensions first, then leave headroom for indexes, business fields, backups, and growth—this is more reliable than copying someone else's "capacity table."

pgvector is a PostgreSQL extension. Its advantage is not "always fastest," but that you can put vectors and relational data such as users, documents, permissions, and orders in the same transaction and backup system.

The current official README supports exact nearest-neighbor search as well as two approximate indexes, HNSW and IVFFlat. HNSW usually offers a better speed-recall trade-off, but builds more slowly and uses more memory; IVFFlat builds more lightly, but its parameters and data distribution affect recall more.

Cases where pgvector fits well:

• You already have a stable PostgreSQL;
• Vector retrieval needs to filter together with many relational conditions;
• Data scale is temporarily small and the team doesn't want to maintain another database;
• You need PostgreSQL transactions, JOINs, WAL, PITR, and existing monitoring tools.

Its pitfalls are also direct: business queries, autovacuum, backups, and HNSW index building all compete for the same database resources. The official documentation also warns that HNSW graphs build faster when they fit in maintenance_work_mem, but setting this value too large may exhaust server memory.

When a small team already has PostgreSQL, pgvector is often the lowest-cost first step; once vector retrieval truly becomes an independent workload, splitting to Qdrant is easier than maintaining three or four component sets from the start.

Qdrant provides independent REST and gRPC interfaces, with vectors, payload, and filtering designed around retrieval scenarios. For RAG knowledge bases, its boundary is clearer than "stuffing another extension into the business database": an application failure doesn't necessarily drag down the vector database, and scaling the vector database doesn't require touching the main business database first.

Qdrant suits these cases:

• Multiple applications share one vector service;
• Payload filtering is part of the retrieval chain;
• You want an independent API to manage collections, points, and snapshots;
• You may later upgrade memory, disk, or split nodes separately.

The cost is that you must handle API Key, TLS, snapshots, upgrades, and monitoring yourself. The self-hosted Qdrant version is not automatically secure after installation, and port 6333 should not be exposed directly to the public internet.

Milvus has deployment modes such as Lite, Standalone, and Distributed. Standalone can run on a single machine; Distributed targets large-scale scenarios beyond single-machine capacity, with significantly increased component and operational complexity.

In Milvus's current official hardware recommendations, Standalone requires a minimum of 8GB and recommends 16GB memory; Cluster requires a minimum of 32GB and recommends 128GB, and disks should be at least SATA SSD, with NVMe recommended. These numbers already show that Milvus is not a peer replacement on a 2-core 4GB small VPS.

When is it worth considering?

• Single-machine resources have been confirmed as a bottleneck through monitoring;
• Data scale, writes, and query volume continue to grow;
• The team can maintain object storage, monitoring, backups, and multi-component upgrades;
• The benefits of distribution outweigh the extra machine and labor costs.

If the project is just starting and you're only worried about "100 million entries in the future," first record data growth, query concurrency, and latency targets. Without these data, distribution is just paying the operations tax in advance.

Below are conservative starting tiers, not capacity guarantees. Different dimensions, index parameters, payload, concurrency, and CPU platforms will spread results widely.

Don't declare the machine sufficient just because queries run on an empty collection. What really fills memory and disk is batch import, index building, filtered queries, and snapshots happening at the same time.

Prepare a batch of data that represents real business: don't casually simplify vector dimensions, text length, tag counts, or filter conditions. First record the data directory size and process memory without indexes, then create the HNSW or IVFFlat index you plan to launch with, and compare disk, memory peaks, and build time before and after indexing.

Then replay real queries: include not only ordinary nearest-neighbor search but also the tenant, permission, time, and category filters the business will use. Testing only single-request average latency is not very meaningful; at minimum observe peak concurrency, P95/P99 latency, error rates, and recall changes at the same time.

Finally, do a failure drill: create a snapshot, transfer the copy elsewhere, delete the test collection, and restore according to the documentation. If recovery time already exceeds the downtime window the business can accept, then even if daily queries are fast, this configuration cannot be considered a pass.

Record the vector count, dimensions, index parameters, disk usage, memory peaks, and query results for each round. Repeat once when data doubles—this is more useful for judging whether to add memory, change disks, or split into an independent service than copying someone else's benchmarks.

Common purchasing priorities for vector retrieval are:

1. Memory headroom: index building and queries both need working sets; running long-term at 95% memory is dangerous.
2. SSD/NVMe random I/O: data, WAL, snapshots, and indexes all read and write disk; looking only at capacity and not latency easily leads to pitfalls.
3. CPU model: index building and distance computation are CPU-intensive; older shared multi-core may not be faster than newer platforms with fewer cores.
4. Backup egress: snapshots must be transferred to another machine or object storage; outbound traffic and speed both affect recovery time.
5. Data center location: keep the vector database as close as possible to the application that calls it; don't make every retrieval cross continents.

Don't count only the VPS in monthly costs:

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

pgvector may save one service but concentrates risk in the main database; Qdrant adds one container but has clear boundaries; Milvus Distributed can scale horizontally but also raises machine count and operational costs together.

The following assumes Ubuntu/Debian, Docker Compose already installed, and Caddy installed on the host. The example pins Qdrant v1.18.3 released on July 17, 2026; do not use latest long-term in production.

Create directories:

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

Generate an API Key and tighten permissions on .env:

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

Create 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

Here 6333 is deliberately bound to 127.0.0.1. It cannot be accessed directly from outside; only through Caddy on the host. If you don't use gRPC, you don't need to expose 6334.

Start and check:

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

If it returns the collection list, the container and authentication are working. If it returns 401, first confirm .env is loaded, the container environment variable exists, and check docker compose logs qdrant.

First point the A/AAAA records of vector.example.com to the VPS, and ensure the firewall only opens SSH, 80, and 443. 6333/tcp does not need public exposure.

Host Caddyfile:

vector.example.com {
    reverse_proxy 127.0.0.1:6333
}

Check and load:

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

Caddy will apply for and renew certificates for a valid domain. Clients must still include Qdrant's api-key request header when accessing:

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

Replace vector.example.com with your own domain. Do not write the API Key into the Caddyfile, Git repository, or frontend JavaScript; it should be kept in server-side environment variables or a secret management system.

Assuming the collection is named docs, create a snapshot:

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

List existing snapshots:

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

The snapshot file is still in the host's /opt/qdrant/snapshots directory. When the machine's disk fails, same-disk snapshots may be lost too, so copy them regularly to object storage or another cloud provider.

Before restoring, read the Qdrant Snapshot documentation corresponding to the current version and validate on a test collection. The API form for uploading a local snapshot is as follows:

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 is the real file path you retrieved from off-site backup. Restoring affects the target collection; don't try it on the production database the first time.

Snapshots, images, and whole-machine backups are not the same thing; you can design a recovery process by referring to the differences between VPS snapshots, backups, and images.

Production upgrades should do at least these steps:

1. Read the target version's release notes and compatibility notes;
2. Create a collection snapshot and copy it off-site;
3. Record the current image version and compose file;
4. Change the image tag to an explicit version before pulling;
5. After startup, check health, collection count, and business queries;
6. Keep the old configuration and backups that can be rolled back.

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

Database upgrades differ from ordinary web containers. Data formats, index rebuilds, and recovery time must all be validated in advance; you cannot consider the upgrade successful just because the container is running.

Observe continuously during business peaks first, not just a single 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

These signals indicate it's time to scale up or split:

• Normal memory approaches the limit, continuous swapping begins, or OOM occurs;
• Business queries time out noticeably during index building;
• Remaining disk space is insufficient to hold data, WAL, and snapshots at the same time;
• Random I/O latency keeps rising;
• Backup windows get longer and longer, and recovery drills cannot complete within the target time;
• The price of vertical single-machine upgrades is already close to multi-node or managed options.

Don't just look at vector count. Stress test with real embeddings, real filter conditions, and concurrency levels, record P95/P99 latency, recall changes, memory peaks, and index build time, then decide whether to add memory, switch to NVMe, do quantization, or split services.

If the project is already in PostgreSQL and vector scale is still small, start with pgvector; if you want to provide an independent interface for multiple RAG applications, 4-core 8GB Qdrant is an easier starting point to manage; if you're sure you need more single-machine resources, evaluate 8-core 16GB+ and Milvus Standalone; only after single-machine bottlenecks are confirmed should you discuss Milvus Distributed.

When buying a VPS, don't squeeze memory too tight just to save a little monthly fee. What vector databases fear most is not average load, but index building, batch import, snapshots, and business queries colliding at the same time. Leaving headroom, pulling 6333 back to localhost, and copying snapshots out are more useful than chasing a benchmark table detached from your dataset.

• Qdrant Quickstart
• Qdrant Security
• Qdrant Snapshots
• Qdrant Monitoring
• pgvector official README
• Milvus installation and deployment modes
• Milvus Docker prerequisites
• Caddy reverse_proxy