Cómo elegir un VPS para bases de datos vectoriales RAG (2026): configuración y costes de Qdrant, pgvector y Milvus

Si solo necesitas un almacén vectorial para Dify, AnythingLLM o tu propia aplicación RAG, elegiría primero entre pgvector y Qdrant. Milvus no está mal, pero "puede que sea muy grande en el futuro" no es razón suficiente para desplegar ahora un sistema distribuido.

En el sitio ya hay un tutorial completo de despliegue de RAG privado con Dify y un tutorial de base de conocimiento privada con AnythingLLM. Este artículo solo resuelve la capa inferior: cómo se almacenan realmente los vectores, cómo comprar la máquina y cómo ejecutar el servicio de forma segura.

"¿Cuánta memoria necesitan 1 millón de vectores?" no tiene una respuesta universal independiente del modelo. Al menos hay que saber:

• Cuántas dimensiones tienen los vectores;
• Si se usa float32, media precisión o datos cuantizados;
• Si se usa búsqueda exacta, HNSW o IVFFlat;
• Cuánto texto, etiquetas y payload de negocio lleva además cada registro;
• Si hay réplicas, WAL, snapshots y consultas concurrentes;
• Cuánta memoria de trabajo necesita la construcción del índice.

Tomando como ejemplo vectores brutos float32, haz primero una estimación mínima:

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

El README oficial de pgvector es más preciso: vector ocupa 4 × dimensions + 8 bytes por entrada. Suponiendo 1536 dimensiones:

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

Esto es solo el vector en sí, sin contar la sobrecarga de fila de PostgreSQL, el grafo HNSW, el payload, la memoria de construcción del índice, la caché y el sistema operativo. Llegados aquí se entiende: un VPS de 4 GB puede hacer validación funcional, pero no puedes prometer que alojará de forma estable 1 millón de entradas HNSW de 1536 dimensiones solo porque "los vectores brutos ocupan solo unos GB".

Si el modelo genera 768 dimensiones, los datos brutos se reducen aproximadamente a la mitad; cambiar a media precisión también puede reducir el conjunto de trabajo, pero trae compromisos de precisión e implementación. Calcula primero el volumen bruto con tus propias dimensiones de embedding y luego deja margen para índices, campos de negocio, copias de seguridad y crecimiento; esto es más fiable que copiar la "tabla de capacidades" de otro.

pgvector es una extensión de PostgreSQL. Su ventaja no es "ser siempre el más rápido", sino que puedes poner vectores y datos relacionales como usuarios, documentos, permisos y pedidos en el mismo sistema de transacciones y copias de seguridad.

El README oficial actual admite búsqueda exacta de vecinos más cercanos y también dos índices aproximados, HNSW e IVFFlat. HNSW suele ofrecer un mejor equilibrio velocidad-recall, pero se construye más lento y usa más memoria; IVFFlat se construye más ligeramente, pero sus parámetros y la distribución de datos afectan más al recall.

Casos en los que pgvector encaja bien:

• Ya tienes un PostgreSQL estable;
• La búsqueda vectorial debe filtrarse junto con muchas condiciones relacionales;
• La escala de datos es temporalmente pequeña y el equipo no quiere mantener otra base de datos;
• Necesitas transacciones, JOIN, WAL, PITR y las herramientas de monitorización existentes de PostgreSQL.

Sus trampas también son directas: las consultas de negocio, el autovacuum, las copias de seguridad y la construcción del índice HNSW compiten por los recursos de la misma base de datos. La documentación oficial también advierte que el grafo HNSW se construye más rápido cuando cabe en maintenance_work_mem, pero poner este valor demasiado alto puede agotar la memoria del servidor.

Cuando un equipo pequeño ya tiene PostgreSQL, pgvector suele ser el primer paso de menor coste; cuando la búsqueda vectorial se convierta realmente en una carga independiente, separarla a Qdrant será más fácil que mantener tres o cuatro conjuntos de componentes desde el principio.

Qdrant ofrece interfaces REST y gRPC independientes, con vectores, payload y filtrado diseñados en torno a escenarios de búsqueda. Para bases de conocimiento RAG, su límite es más claro que "meter otra extensión en la base de datos de negocio": si la aplicación falla, no necesariamente arrastra a la base vectorial, y escalar la base vectorial no requiere tocar primero la base de datos principal de negocio.

Qdrant encaja en estos casos:

• Varias aplicaciones comparten un servicio vectorial;
• El filtrado por payload forma parte de la cadena de búsqueda;
• Quieres una API independiente para gestionar colecciones, puntos y snapshots;
• Puede que más adelante quieras ampliar memoria, disco o separar nodos.

El coste es que debes gestionar tú mismo la API Key, TLS, los snapshots, las actualizaciones y la monitorización. La versión autoalojada de Qdrant no es segura automáticamente tras instalarla, y el puerto 6333 no debería exponerse directamente a Internet.

Milvus tiene modos de despliegue como Lite, Standalone y Distributed. Standalone puede ejecutarse en una sola máquina; Distributed está orientado a escenarios a gran escala que superan la capacidad de una sola máquina, con una complejidad de componentes y operaciones notablemente mayor.

En las recomendaciones oficiales actuales de hardware de Milvus, Standalone requiere un mínimo de 8 GB y recomienda 16 GB de memoria; Cluster requiere un mínimo de 32 GB y recomienda 128 GB, y el disco debe ser al menos SATA SSD, con NVMe recomendado. Estas cifras ya muestran que Milvus no es un sustituto equivalente en un VPS pequeño de 2 núcleos 4 GB.

¿Cuándo merece la pena considerarlo?

• Los recursos de una sola máquina ya se han confirmado como cuello de botella mediante monitorización;
• La escala de datos, las escrituras y el volumen de consultas siguen creciendo;
• El equipo puede mantener almacenamiento de objetos, monitorización, copias de seguridad y actualizaciones de varios componentes;
• Los beneficios de la distribución superan los costes adicionales de máquinas y personal.

Si el proyecto acaba de empezar y solo te preocupa "tener 100 millones de entradas en el futuro", primero registra el crecimiento de datos, la concurrencia de consultas y los objetivos de latencia. Sin estos datos, la distribución solo es pagar el impuesto operativo por adelantado.

Las siguientes son franjas iniciales conservadoras, no garantías de capacidad. Distintas dimensiones, parámetros de índice, payload, concurrencia y plataformas de CPU harán que los resultados varíen mucho.

No declares que la máquina es suficiente solo porque las consultas funcionan en una colección vacía. Lo que realmente llena la memoria y el disco es la importación por lotes, la construcción de índices, las consultas filtradas y los snapshots ocurriendo al mismo tiempo.

Prepara un lote de datos que represente el negocio real: no simplifiques a la ligera las dimensiones vectoriales, la longitud del texto, el número de etiquetas ni las condiciones de filtrado. Primero registra el tamaño del directorio de datos y la memoria del proceso sin índices, luego crea el índice HNSW o IVFFlat con el que piensas lanzar y compara disco, picos de memoria y tiempo de construcción antes y después de indexar.

Después reproduce consultas reales: incluye no solo búsqueda de vecinos más cercanos normal, sino también los filtros de inquilino, permisos, tiempo y categoría que usará el negocio. Probar solo la latencia media de una sola petición tiene poco sentido; como mínimo observa al mismo tiempo la concurrencia en hora punta, la latencia P95/P99, la tasa de errores y los cambios de recall.

Por último, haz un simulacro de fallo: crea un snapshot, transfiere la copia a otro lugar, elimina la colección de prueba y restaura según la documentación. Si el tiempo de recuperación ya supera la ventana de inactividad que el negocio puede aceptar, aunque las consultas diarias sean rápidas, esta configuración no puede considerarse aprobada.

Registra en cada ronda el número de vectores, dimensiones, parámetros de índice, uso de disco, picos de memoria y resultados de consultas. Repite una vez cuando los datos se dupliquen; esto sirve más para decidir si añadir memoria, cambiar discos o separar en un servicio independiente que copiar los benchmarks de otros.

Las prioridades de compra habituales para búsqueda vectorial son:

1. Margen de memoria: la construcción de índices y las consultas necesitan conjuntos de trabajo; operar a largo plazo al 95 % de memoria es peligroso.
2. I/O aleatorio SSD/NVMe: datos, WAL, snapshots e índices leen y escriben en disco; fijarse solo en la capacidad y no en la latencia lleva fácilmente a problemas.
3. Modelo de CPU: construir índices y calcular distancias consume CPU; un multinúcleo compartido antiguo no necesariamente es más rápido que una plataforma nueva con menos núcleos.
4. Salida de copias de seguridad: los snapshots deben transferirse a otra máquina o almacenamiento de objetos; el tráfico de salida y la velocidad afectan al tiempo de recuperación.
5. Ubicación del centro de datos: mantén la base vectorial lo más cerca posible de la aplicación que la llama; no hagas que cada búsqueda cruce continentes.

Tampoco calcules solo el VPS en el coste mensual:

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

pgvector puede ahorrar un servicio, pero concentra el riesgo en la base de datos principal; Qdrant añade un contenedor, pero con límites claros; Milvus Distributed puede escalar horizontalmente, pero también eleva a la vez el número de máquinas y el coste operativo.

Lo siguiente asume Ubuntu/Debian, Docker Compose ya instalado y Caddy instalado en el host. El ejemplo fija Qdrant v1.18.3, publicado el 17 de julio de 2026; no uses latest a largo plazo en producción.

Crear directorios:

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

Generar una API Key y restringir los permisos de .env:

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

Crear 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

Aquí el 6333 se vincula deliberadamente a 127.0.0.1. No se puede acceder directamente desde fuera; solo a través de Caddy en el host. Si no usas gRPC, no hace falta exponer el 6334.

Iniciar y comprobar:

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

Si devuelve la lista de colecciones, el contenedor y la autenticación funcionan. Si devuelve 401, confirma primero que .env está cargado, que existe la variable de entorno del contenedor y revisa docker compose logs qdrant.

Primero apunta los registros A/AAAA de vector.example.com al VPS y asegúrate de que el firewall solo abre SSH, 80 y 443. 6333/tcp no necesita exposición pública.

Caddyfile del host:

vector.example.com {
    reverse_proxy 127.0.0.1:6333
}

Comprobar y cargar:

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

Caddy solicitará y renovará certificados para un dominio válido. Los clientes deben seguir incluyendo la cabecera de solicitud api-key de Qdrant al acceder:

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

Sustituye vector.example.com por tu propio dominio. No escribas la API Key en el Caddyfile, en el repositorio Git ni en el JavaScript del frontend; debe guardarse en variables de entorno del servidor o en un sistema de gestión de secretos.

Suponiendo que la colección se llama docs, crea un snapshot:

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

Listar los snapshots existentes:

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

El archivo de snapshot sigue en el directorio /opt/qdrant/snapshots del host. Si el disco de la máquina falla, los snapshots en el mismo disco pueden perderse también, así que cópialos periódicamente a almacenamiento de objetos o a otro proveedor de nube.

Antes de restaurar, lee la documentación de Qdrant Snapshot correspondiente a la versión actual y valida en una colección de prueba. La forma de la API para subir un snapshot local es la siguiente:

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 es la ruta real del archivo que recuperaste de la copia de seguridad externa. La restauración afecta a la colección de destino; no lo pruebes la primera vez en la base de datos de producción.

Los snapshots, las imágenes y las copias de seguridad de toda la máquina no son lo mismo; puedes diseñar el proceso de recuperación consultando las diferencias entre snapshots, copias de seguridad e imágenes de VPS.

Una actualización de producción debe hacer al menos estos pasos:

1. Leer las release notes y las notas de compatibilidad de la versión objetivo;
2. Crear un snapshot de la colección y copiarlo fuera del sitio;
3. Registrar la versión actual de la imagen y el archivo compose;
4. Cambiar la etiqueta de la imagen a una versión explícita antes de hacer pull;
5. Tras iniciar, comprobar la salud, el número de colecciones y las consultas de negocio;
6. Conservar la configuración antigua y las copias de seguridad que permitan revertir.

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

Las actualizaciones de bases de datos son distintas de los contenedores web normales. Los formatos de datos, la reconstrucción de índices y el tiempo de recuperación deben validarse de antemano; no puedes considerar la actualización exitosa solo porque el contenedor esté running.

Observa primero de forma continua durante las horas punta del negocio, no solo un ú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

Estas señales indican que hay que ampliar o separar:

• La memoria normal se acerca al límite, empieza el swapping continuo o aparecen OOM;
• Las consultas de negocio superan claramente el tiempo de espera durante la construcción de índices;
• El espacio libre en disco no basta para guardar a la vez datos, WAL y snapshots;
• La latencia de I/O aleatorio sigue subiendo;
• La ventana de copia de seguridad se alarga cada vez más y los simulacros de recuperación no se completan en el tiempo objetivo;
• El precio de la ampliación vertical de una sola máquina ya se acerca al de opciones multinodo o gestionadas.

No mires solo el número de vectores. Haz pruebas de carga con embeddings reales, condiciones de filtrado reales y niveles de concurrencia, registra la latencia P95/P99, los cambios de recall, los picos de memoria y el tiempo de construcción de índices, y luego decide si añadir memoria, cambiar a NVMe, hacer cuantización o separar servicios.

Si el proyecto ya está en PostgreSQL y la escala vectorial aún es pequeña, empieza con pgvector; si quieres ofrecer una interfaz independiente a varias aplicaciones RAG, Qdrant de 4 núcleos 8 GB es un punto de partida más fácil de gestionar; si estás seguro de que necesitas más recursos en una sola máquina, evalúa 8 núcleos 16 GB+ y Milvus Standalone; solo cuando los cuellos de botella de una sola máquina estén confirmados, habla de Milvus Distributed.

Al comprar un VPS, no aprietes demasiado la memoria solo por ahorrar un poco en la cuota mensual. Lo que más teme una base de datos vectorial no es la carga media, sino que la construcción de índices, la importación por lotes, los snapshots y las consultas de negocio coincidan al mismo tiempo. Dejar margen, devolver el 6333 a localhost y copiar los snapshots fuera es más útil que perseguir una tabla de benchmarks desconectada de tu conjunto de datos.

• Qdrant Quickstart
• Qdrant Security
• Qdrant Snapshots
• Qdrant Monitoring
• README oficial de pgvector
• Modos de instalación y despliegue de Milvus
• Requisitos previos de Milvus Docker
• Caddy reverse_proxy