Bases de Datos Vectoriales en Producción: Cómo Elegir la Correcta
Los benchmarks de QPS no cuentan la historia completa. Framework de decisión real para elegir vector DB basado en filtrado, escala, operaciones y coste — con los puntos de rotura documentados de cada opción.
“¿Cuál es la más rápida?”
La semana pasada, un CTO me mandó un spreadsheet con seis bases de datos vectoriales comparadas por QPS y latencia p99. Seis columnas perfectas. Me pidió que le ayudara a elegir entre Qdrant y Pinecone.
Le hice tres preguntas: cuántos vectores tiene ahora, si ya usa PostgreSQL, y cuántas personas hay en su equipo de infraestructura. Tres millones, sí, y “básicamente yo a media jornada”. La respuesta era pgvector. Ninguna columna de su spreadsheet le habría llevado ahí.
Elegir base de datos vectorial por QPS es como elegir coche por velocidad máxima. Lo que necesitas es que no se rompa, que puedas aparcar donde vives y que te alcance para el seguro.
Por qué los benchmarks mienten (un poco)
He caído en esta trampa. Cuando empecé a montar sistemas RAG en producción, leía los benchmarks de los vendors y tomaba decisiones basándome en ellos. No tardé mucho en darme cuenta de que cada uno publica el benchmark donde gana.
VDBBench muestra a Milvus/Zilliz con 9.704 QPS a 10 millones de vectores. Impresionante. También es un benchmark de Zilliz — los creadores de Milvus. Los benchmarks de Timescale muestran a pgvectorscale con 28x mejor p95 que Pinecone s1. Timescale creó pgvectorscale. Los benchmarks de Qdrant muestran que su filtrado apenas impacta latencia. Qdrant publicó esos benchmarks.
¿Ves el patrón?
La fuente más honesta que tenemos es ANN-Benchmarks, pero compara algoritmos de indexación, no bases de datos completas. Para comparaciones cloud-a-cloud, benchANT es lo más neutral que hay — y sus números suelen ser menos generosos con todos.
Lo que sí me ha servido: los issues de GitHub, los post-mortems, los threads de Discord donde alguien cuenta que a 20 millones de vectores todo se fue al garete. Esos datos no tienen departamento de marketing.
Lo que realmente importa cuando eliges
Después de ver suficientes de estos sistemas funcionar — y romperse — he destilado cinco preguntas que importan más que cualquier benchmark:
¿Cómo filtra tu sistema? En producción, casi ninguna query es “busca los 10 vectores más similares” a secas. Casi todas llevan filtro: cliente X, documentos de este año, este tag de producto. He visto bases de datos que en benchmarks puros volaban y con filtros multi-tenant no daban la talla. El rendimiento con filtros es la métrica que nadie pone en la landing page y la que más impacta tu caso real.
¿A cuánto vas a llegar de verdad? No en teoría — en los próximos 12 meses. “Soporta billones de vectores” en la documentación y funcionar sin degradación con tu volumen real son cosas muy distintas.
¿Quién va a operar esto? Milvus lidera benchmarks. También requiere Kubernetes, etcd y MinIO. Si tu equipo de infra es una persona a media jornada, no es una opción real. He visto más proyectos hundirse por no poder operar la infraestructura que por elegir la base de datos equivocada.
¿Qué ya tienes montado? Si ya corres PostgreSQL para todo lo demás, añadir pgvector es un CREATE EXTENSION. Meter un sistema distribuido nuevo tiene un coste que no aparece en ninguna comparativa: onboarding, monitorización, backups, otra cosa que puede fallar a las 3 de la mañana.
¿Cuánto va a costar cuando crezcas? Todos los precios parecen razonables con un millón de vectores. Un equipo con el que trabajé arrancó con Pinecone porque era zero-ops — razonable. A los seis meses tenían 40 millones de vectores y una factura mensual que nadie había presupuestado.
La comparativa sin marketing
He eliminado las features de marketing y me he centrado en lo que importa cuando tienes que mantener un sistema en producción:
| pgvector | Qdrant | Weaviate | Pinecone | Milvus/Zilliz | Chroma | LanceDB | |
|---|---|---|---|---|---|---|---|
| Escala confortable | Hasta 5M | Hasta 10M (single) | Hasta 50M | Billions (managed) | Billions | Hasta 100K | Billions (S3) |
| Filtrado | Problemático (post-filter) | Mejor (≤10% impacto) | Bueno | Moderado (30-50% más lento) | Bueno | Básico | Bueno |
| Latencia p99 | Sub-100ms | 1-6ms | Sub-100ms | 7-14ms | 2-3ms | N/A | 3-10ms |
| Hybrid search | ts_vector + vector | Sparse + dense | BM25F nativo (mejor) | Sparse-dense | Sparse + dense | Básica | FTS + vector |
| Cuantización | Binary, SBQ (pgvectorscale) | Scalar, binary, PQ, 1.5-bit | PQ, BQ | Auto | SQ8, PQ, binary | Limitada | PQ |
| DiskANN | ✅ (pgvectorscale) | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
| Self-hosted | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ |
| Coste ~1M×768d | $50-150/mo (VM) | ~$27/mo (cloud) | ~$25/mo | $50+/mo | ~$99/mo (Zilliz) | Gratis | Gratis |
| Coste ~50M×1536d | ~$200-400/mo | ~$500-1K/mo | ~$500-1K/mo | ~$3.000-3.500/mo | ~$500-1K/mo | No viable | Coste S3 |
Donde cada una se rompe
Los números bonitos están arriba. Ahora, lo que no aparece en los blog posts de marketing.
pgvector funciona genial hasta ~5 millones de vectores con un PostgreSQL bien tuneado. Lo he recomendado docenas de veces y para la mayoría de equipos es la decisión correcta — sobre todo si ya tienen Postgres. Pero los límites son reales y están documentados en su repositorio: builds de índice HNSW atascados más de 19 horas, crashes con 17 millones de vectores a 1.536 dimensiones en máquinas de 48 CPUs y 192 GB de RAM. He visto algo similar de primera mano: un equipo que cambió de modelo de embeddings con 15 millones de vectores y tuvo que reindexar. El build de HNSW tardó toda la noche y durante ese tiempo las búsquedas estaban degradadas — en un sistema que la gente usaba a diario. pgvectorscale con DiskANN resuelve buena parte de esto, pero es una dependencia extra sobre tu Postgres.
Qdrant es mi favorita en single-node. El rendimiento con filtros es el mejor del mercado — menos del 10% de impacto en latencia cuando añades condiciones de metadata. Esto me ha salvado en proyectos multi-tenant donde cada query lleva un filtro de organización obligatorio. Soporte de cuantización es el más completo que hay (scalar, binary, product, hasta 1.5-bit). Pero degrada significativamente más allá de 10-50 millones en un solo nodo — en un benchmark de Timescale, cayó a 41 QPS a 50 millones de vectores. Clustering existe pero añade complejidad operacional.
Weaviate tiene la mejor búsqueda híbrida nativa: BM25F + vector con Reciprocal Rank Fusion en un solo API call. Si la búsqueda híbrida es central en tu caso de uso, aquí vas a encontrar menos fricción que en ningún otro sitio. Para RAG empresarial — rara vez más de 50M vectores — es una opción sólida. Cuidado por encima de 100 millones: el consumo de recursos escala fuerte.
Pinecone es zero-ops, y eso tiene un valor real. Pero el vendor lock-in es total — no hay opción self-hosted — y el filtrado de metadata es 30-50% más lento. Y luego está el coste: 50 millones de embeddings pueden salir por $3.000-3.500 al mes. He visto equipos que empezaron con Pinecone por comodidad y después no podían migrar porque todo su pipeline dependía de la API propietaria. Zero-ops no significa zero-riesgo.
Milvus/Zilliz es la opción billion-scale. Mayor QPS documentado (9.704 en Zilliz, 3.465 self-hosted), aceleración GPU con NVIDIA cuVS que da 21x más velocidad en indexación, deployment documentado de 100 billion vectores. Si necesitas esa escala, no hay alternativa real. Pero operar Milvus self-hosted es Kubernetes + etcd + MinIO — no es un docker run y olvidarte. Zilliz Cloud simplifica las operaciones a cambio de precio.
Chroma es para prototipos. He perdido la cuenta de cuántas veces he visto esto: un equipo prototipa con Chroma, funciona genial con 50K documentos de test, y asumen que escalará. No escala. Single-node, sin alta disponibilidad, degrada notablemente a partir de 100K vectores. Para desarrollo es cómodo. Para producción, planifica la migración antes de que te pille.
LanceDB es la opción serverless sobre S3. El formato Lance ofrece hasta 1.000x acceso aleatorio más rápido que Parquet. Hay deployments documentados de 1B vectores en S3 con Lambda. Interesante si priorizas coste sobre latencia mínima. Ecosistema todavía joven, pero el modelo económico a escala es difícil de ignorar.
HNSW vs DiskANN: cuándo importa
La mayoría de bases de datos usan HNSW por defecto, y con razón — a recall altos, es el más rápido según ANN-Benchmarks. Pero todo tiene que caber en RAM. Un millón de vectores a 1.536 dimensiones en float32 son ~5.7 GB brutos. Con overhead de HNSW: 7-17 GB dependiendo de la implementación. A 50 millones estás en cientos de GB. A un billón, inviable.
DiskANN indexa en disco NVMe con un grafo comprimido en RAM. Puede manejar más de mil millones de vectores en una sola máquina con 64 GB de RAM, con más del 95% de recall@1 y latencia inferior a 5ms. Hoy solo pgvectorscale y Milvus lo soportan.
En la práctica: si estás por debajo de 50 millones de vectores, HNSW con cuantización es suficiente. DiskANN empieza a importar cuando la factura de RAM se convierte en tu principal problema de infraestructura.
Cuantización: cuándo merece la pena
En un proyecto reciente, un equipo estaba escalando de 5 a 30 millones de vectores y la RAM se les estaba comiendo el presupuesto. La solución no fue más servidores — fue cuantización.
La cuantización binaria convierte cada float32 (4 bytes) en 1 bit. 32x de reducción de almacenamiento. Pero sin rescoring retienes ~92.5% del rendimiento. Con rescoring — reordenar los top-K contra los vectores originales — subes a ~96%.
| Método | Compresión | Recall retenido | Speedup |
|---|---|---|---|
| float32 (baseline) | 1x | 100% | 1x |
| Scalar int8 | 4x | ~99-100% | ~3.7x |
| Binary 1-bit | 32x | ~92-96% (con rescoring) | ~25x |
La combinación Matryoshka + binario es donde el ahorro se vuelve absurdo: Voyage AI documenta 1/200 del almacenamiento con solo 1.16% de pérdida de calidad.
Mi regla: por debajo de 10 millones, scalar int8 da 4x de ahorro con pérdida despreciable y casi no cambia tu pipeline. Más allá de 50 millones, la cuantización binaria con rescoring pasa de optimización a necesidad. El equipo del que hablaba pasó de necesitar 170 GB de RAM a 5 GB. Mismo recall, fracción del coste.
Cómo decido en la práctica
Esto es literalmente lo que pregunto cuando alguien me consulta:
¿Ya usas PostgreSQL y tienes menos de 5M vectores? → pgvector. No añadas complejidad innecesaria. Si necesitas crecer: pgvectorscale con DiskANN, sin cambiar de ecosistema.
¿Filtrado agresivo es clave (multi-tenant, metadata compleja)? → Qdrant. El impacto en latencia al filtrar es mínimo y no lo iguala ninguna otra.
¿Hybrid search es central (términos exactos + semántica)? → Weaviate. Su BM25F + vector nativo es lo más limpio que hay. Para entender por qué la búsqueda híbrida debería ser tu baseline: Tu Búsqueda Vectorial Tiene un Punto Ciego.
¿No quieres operar infraestructura, punto? → Pinecone. Acepta el coste y el lock-in a cambio de cero operaciones. Pero presupuesta con margen — los costes escalan más rápido de lo que esperas.
¿Billion-scale, GPUs disponibles, equipo DevOps sólido? → Milvus o Zilliz Cloud. No hay nada que le iguale en rendimiento bruto a esa escala.
¿Serverless, multimodal, coste mínimo? → LanceDB sobre S3. Ideal si toleras algo más de latencia a cambio de costes mínimos.
¿Prototipo? → Chroma. Pero ten lista la migración antes de que el primer usuario real toque el sistema.
Lo que me llevo
La base de datos vectorial es infraestructura, no diferenciación. Ninguna va a hacer que tu RAG dé mejores respuestas — eso depende de cómo cortas los documentos, qué modelo de embeddings usas y si implementas búsqueda híbrida o no.
Lo que sí puede hacer una mala elección es hundir tu sistema: por coste, por degradación a escala, o por una decisión que parecía razonable con un millón de vectores y se vuelve insostenible con cincuenta.
Elige por puntos de rotura, no por puntos fuertes. Todos los vendors te van a contar dónde brillan. Nadie te va a contar dónde se rompen.
Eso te toca descubrirlo antes de llegar a producción — no después.
Este artículo forma parte de nuestra serie sobre arquitectura RAG en producción. Si tu equipo necesita orientación sobre qué stack montar — o quiere auditar el que ya tiene — hablemos.