{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone","title":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","description":"Benchmarks honestos comparando pgvector 0.8, Qdrant, Pinecone y Weaviate para un pipeline RAG real. Indexación HNSW vs IVF, tradeoffs de cuantización, latencia a escala, y recomendaciones prácticas para diferentes case es de uso.","language":"es","datePublished":"2025-12-02","dateModified":null,"contentFormat":"text/markdown","content":"AI/ML\n\n# Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate\n\n2025-12-029 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/vector-databases-pgvector-qdrant-pinecone>)\n\n## El Setup de Test\n\n**Dataset**: 2.3M chunks de documentos de una base de conocimiento de soporte al cliente. Tamaño promedio de chunk: 512 tokens. Embeddeado con ` text-embedding-3-small ` (1536 dimensiones).\n\n**Queries**: 10,000 queries reales de usuarios recolectadas de logs de producción (anonimizadas). Mix de cortas (\"resetear contraseña\"), medianas (\"cómo configurar SSO con Azure AD\"), y largas (\"nuestro equipo está migrando de on-premise a cloud y necesitamos entender las implicaciones de residencia de datos para cumplimiento GDPR\").\n\n**Hardware**:\n\n- pgvector: RDS ` db.r7g.xlarge ` (4 vCPU, 32GB RAM), PostgreSQL 16 con pgvector 0.8\n- Qdrant: cluster de 3 nodos en ` c7g.xlarge ` (4 vCPU, 8GB RAM cada uno), Qdrant 1.13\n- Pinecone: Serverless (Standard), us-east-1\n- Weaviate: cluster de 3 nodos en ` c7g.xlarge `, Weaviate 1.28\n\n**Búsqueda**: Top-10 vecinos más cercanos, similaridad coseno, con filtro de metadata (categoría = valor específico, reduciendo candidatos en ~80%).\n\n## Números Crudos: Latencia y Throughput\n\n### Latencia de Query (10K queries, ms)\n\n| Base de datos | p50 | p95 | p99 | p99.9 |\n| --- | --- | --- | --- | --- |\n| pgvector (HNSW) | 8.2 | 14.1 | 22.3 | 41.7 |\n| pgvector (IVF) | 12.4 | 24.8 | 38.1 | 67.2 |\n| Qdrant | 3.1 | 5.8 | 8.4 | 14.2 |\n| Pinecone Serverless | 18.4 | 32.1 | 48.7 | 142.3 |\n| Weaviate | 5.7 | 11.2 | 18.9 | 33.4 |\n\nQdrant gana en latencia cruda, y no es ni cerca. Su engine basado en Rust con almacenamiento memory-mapped es genuinamente rápido. Pero observar el p99.9 de Pinecone, ese es 142ms de cola son el cold start serverless afectando el rendimiento. Para aplicaciones interactivas, esa cola es un problema.\n\npgvector con HNSW es sorprendentemente competitivo. Con 8.2ms de p50, es suficientemente rápido para cualquier aplicación RAG. La brecha se amplía en la cola, pero para la mayoría de los case es de uso, es más que adecuado.\n\n### Throughput (queries/segundo, 100 conexiones concurrentes)\n\n| Base de datos | QPS (sin filtro) | QPS (con filtro) | Delta |\n| --- | --- | --- | --- |\n| pgvector (HNSW) | 2,840 | 2,120 | -25.4% |\n| Qdrant | 8,420 | 7,180 | -14.7% |\n| Pinecone | 1,200 | 980 | -18.3% |\n| Weaviate | 4,100 | 3,250 | -20.7% |\n\nLa diferencia de performance con filtrado es reveladora. pgvector pierde 25% de throughput con filtros porque los aplica post-búsqueda HNSW (una limitación conocida). Qdrant integra el filtrado en el algoritmo de búsqueda, así que la penalidad es menor. Weaviate cae en algún punto intermedio.\n\nEl techo de throughput de Pinecone es notablemente más bajo de lo que se esperaría para un servicio managed. La arquitectura serverless prioriza optimización de costo por query sobre throughput crudo.\n\n## HNSW vs IVF: Cuándo Gana Cada Uno\n\npgvector 0.8 soporta tanto índices HNSW como IVF-Flat. La elección importa más de lo que la mayoría cree.\n\n### HNSW (Hierarchical Navigable Small World)\n\n```sql\nCREATE INDEX ON documents\nUSING hnsw (embedding vector_cosine_ops)\nWITH (m = 16, ef_construction = 256);\n\n-- Al momento de la query\nSET hnsw.ef_search = 100;\n```\n\n**Pros**: Queries rápidas, alto recall, sin paso de entrenamiento **Contras**: Alto uso de memoria (~1.5x los datos de vectores), builds de índice lentos\n\nTiempo de build HNSW para 2.3M vectores a 1536 dimensiones: **47 minutos** en nuestra instancia RDS. Uso de memoria: **14.2GB** solo para el índice.\n\n### IVF-Flat (Inverted File con cuantización Flat)\n\n```sql\nCREATE INDEX ON documents\nUSING ivfflat (embedding vector_cosine_ops)\nWITH (lists = 1500);\n\n-- Al momento de la query\nSET ivfflat.probes = 40;\n```\n\n**Pros**: Menor uso de memoria (~0.3x), builds de índice más rápidos **Contras**: Requiere entrenamiento (el parámetro lists necesita tuning), menor recall a la misma latencia\n\nTiempo de build IVF: **12 minutos**. Memoria: **4.1GB**. Pero el recall a la misma latencia fue 91.2% vs 97.8% de HNSW.\n\n### Recomendación\n\nUsar HNSW a menos que la memoria sea la restricción principal. La diferencia de recall (97.8% vs 91.2%) significa que por cada 100 queries, IVF se pierde ~7 resultados relevantes que HNSW encuentra. En un pipeline RAG, ese es chunks perdidos impactan directamente la calidad de las respuestas.\n\n## Cuantización: El Tradeoff de Memoria vs Calidad\n\nCon 2.3M vectores a 1536 dimensiones (float32), los datos crudos de vectores son aproximadamente **13.4GB**. La cuantización reduce esto dramáticamente:\n\n### pgvector: halfvec (float16)\n\n```sql\n-- pgvector 0.8 soporta halfvec nativamente\nALTER TABLE documents\n ALTER COLUMN embedding TYPE halfvec(1536);\n\nCREATE INDEX ON documents\nUSING hnsw (embedding halfvec_cosine_ops);\n```\n\nReducción de memoria: 50%. Impacto en recall: **-0.8%** (despreciable). Esto es un decisión evidente para usuarios de pgvector.\n\n### Qdrant: Cuantización Binaria con Rescoring\n\n```json\n{\n \"collection_name\": \"documents\",\n \"vectors\": {\n \"size\": 1536,\n \"distance\": \"Cosine\",\n \"quantization_config\": {\n \"binary\": {\n \"always_ram\": true\n }\n }\n }\n}\n```\n\nLa cuantización binaria reduce cada float32 a un solo bit. 32x de reducción de memoria. Pero el recall crudo baja a ~85%. El truco es el **rescoring**: Qdrant primero busca en el índice binario para obtener un conjunto de candidatos (digamos, top-100), después re-evalúa ese es candidatos contra los vectores de precisión completa. Recall final: **94.7%** con una fracción de la memoria.\n\nEn las pruebas de benchmark:\n\n| Modo Qdrant | Memoria | Latencia p50 | Recall@10 |\n| --- | --- | --- | --- |\n| Precisión completa | 14.8GB | 3.1ms | 98.2% |\n| Binario (sin rescore) | 0.46GB | 1.2ms | 84.9% |\n| Binario + rescore 100 | 0.46GB + 14.8GB disco | 4.8ms | 94.7% |\n| Escalar (int8) | 3.7GB | 2.8ms | 96.1% |\n\nLa cuantización escalar (int8) es el punto dulce para la mayoría: 75% de reducción de memoria con solo 2.1% de pérdida de recall.\n\n## La Pregunta de la Búsqueda Híbrida\n\nLos pipelines RAG reales no hacen solo búsqueda vectorial. Necesitás matching de keywords, filtrado de metadata, y muchas veces ambos combinados.\n\n### pgvector: La Ventaja Injusta\n\n```sql\nWITH vector_results AS (\n SELECT id, content,\n 1 - (embedding <=> $1::vector) AS vector_score\n FROM documents\n WHERE category = $2\n ORDER BY embedding <=> $1::vector\n LIMIT 20\n),\ntext_results AS (\n SELECT id, content,\n ts_rank(search_vector, plainto_tsquery($3)) AS text_score\n FROM documents\n WHERE category = $2\n AND search_vector @@ plainto_tsquery($3)\n LIMIT 20\n)\nSELECT COALESCE(v.id, t.id) AS id,\n COALESCE(v.content, t.content) AS content,\n COALESCE(v.vector_score, 0) * 0.7 +\n COALESCE(t.text_score, 0) * 0.3 AS combined_score\nFROM vector_results v\nFULL OUTER JOIN text_results t ON v.id = t.id\nORDER BY combined_score DESC\nLIMIT 10;\n```\n\nEsta es la característica más destacada de pgvector: búsqueda híbrida en una sola query, con todo el poder del query planner de PostgreSQL. Sin orquestación externa, sin índice de keywords separado, sin fusión de resultados en código de aplicación.\n\n### Weaviate: Híbrido Built-in\n\n```graphql\n{\n Get {\n Document(\n hybrid: {\n query: \"configuración SSO Azure AD\"\n alpha: 0.7\n fusionType: relativeScoreFusion\n }\n where: {\n path: [\"category\"]\n operator: Equal\n valueText: \"authentication\"\n }\n limit: 10\n ) {\n content\n _additional { score }\n }\n }\n}\n```\n\nWeaviate tiene la mejor historia de búsqueda híbrida entre las bases vectoriales dedicadas. El parámetro ` alpha ` controla el peso vector vs keyword.\n\n## Análisis de Costos (La Parte Que Decide)\n\nPara 2.3M vectores a 1536 dimensiones, corriendo 24/7:\n\n| Base de datos | Costo Mensual | Notas |\n| --- | --- | --- |\n| pgvector (RDS r7g.xlarge) | $412 | Incluye cómputo + almacenamiento |\n| pgvector (Neon Pro) | $69-190 | Escala a cero, pago por query |\n| pgvector (Supabase Pro) | $75-200 | Incluye otras features de Postgres |\n| Qdrant Cloud (3 nodos) | $720 | Cluster dedicado |\n| Qdrant (self-hosted EC2) | $390 | 3x c7g.xlarge |\n| Pinecone Serverless | $280-650 | Depende del volumen de queries |\n| Weaviate Cloud | $580 | Managed 3 nodos |\n\npgvector en [Neon](<https://neon.com/>) o [Supabase](<https://supabase.com/>) es absurdamente barato para workloads chicos a medianos. Y como es solo Postgres, no se está pagando un servicio separado, tus vectores viven al lado de tus datos relacionales.\n\nPara workloads de alto throughput (\\>1000 QPS sostenido), Qdrant self-hosted en instancias ARM es el ganador en relación precio-performance.\n\nEl pricing serverless de Pinecone es atractivo a volúmenes bajos pero escala de forma impredecible. En un caso, los patrones de queries cambiaron y la factura saltó 2.3x.\n\n## Recomendaciones Prácticas\n\n**Para la mayoría de startups y MVPs**: pgvector en Supabase o Neon. Teners una base de datos vectorial y una base relacional en una. La búsqueda híbrida funciona de una. La latencia es suficientemente buena. Siempre es posible migrar después si lo superás, y en la práctica, la mayoría de los productos nunca lo harán.\n\n**Para producción de alto throughput y sensible a latencia**: Qdrant. El engine en Rust es genuinamente más rápido, las opciones de cuantización te dan control fino sobre el tradeoff memoria/recall, y el filtrado está bien integrado. Self-hostealo en instancias Graviton para la mejor relación precio-rendimiento.\n\n**Para equipos que quieren todo managed y no les importa el costo**: Pinecone. Funciona, es simple, y no teners que pensar en infraestructura. Solo sepa que se está pagando un premium por esa simplicidad, y los cold starts serverless resultarán problemáticos.\n\n**Para aplicaciones heavy en búsqueda híbrida**: Weaviate si se desea una DB vectorial dedicada, pgvector si se desea la flexibilidad de SQL.\n\n## La Verdad Incómoda\n\nAquí va lo que nadie en el espacio de bases vectoriales quiere admitir: para el 90% de las aplicaciones RAG, pgvector es suficiente. Las bases vectoriales dedicadas son más rápidas, pero \"más rápido\" significa 3ms vs 8ms, ambas son invisibles para el usuario final que está esperando 800ms a que el LLM genere una respuesta.\n\nEl diferenciador real es a escala (\\>10M vectores), a throughput extremo (\\>5000 QPS), o cuando se necesita latencia p99 sub-5ms para aplicaciones en tiempo real. Si esa es la situación, Qdrant o Weaviate valen la complejidad operacional. Si no, y ser honesto sobre si lo es, simplemente utilizar pgvector y dedicar tu tiempo de ingeniería a lo que realmente mueve la aguja: mejores estrategias de chunking, mejores prompts, y mejor evaluación.\n\nLa elección aburrida muchas veces es la correcta.\n\n## Preguntas frecuentes\n\n### ¿Debería usar una base de datos vectorial dedicada o simplemente pgvector?\n\nPara la mayoría de las aplicaciones bajo 5M de vectores, pgvector es la elección correcta, evitás complejidad operacional y es posible hacer queries híbridas joineando vectores con datos relacionales. Arriba de 10M de vectores o si se necesita latencia p99 sub-10ms, las bases vectoriales dedicadas empiezan a justificar su complejidad.\n\n### ¿Qué dimensión de embedding debería usar?\n\nPara la mayoría de aplicaciones RAG, 768 o 1024 dimensiones de un modelo como text-embedding-3-small es el punto dulce. Ir a 1536 o 3072 dimensiones rara vez mejora la calidad de retrieval lo suficiente para justificar el costo 2-4x en almacenamiento y latencia.\n\n### ¿Cuánto degrada la calidad de búsqueda vectorial con la cuantización?\n\nCon cuantización escalar (float32 a int8), el recall baja 1-3%. Con cuantización binaria más rescoring, el recall baja solo 2-5% mientras reduce la memoria 32x. La cuantización de producto puede perder 5-10% de recall pero ahorra más espacio.\n\n## Tips\n\n1. **Win de pgvector:** Utilizar índices ` HNSW ` con ` vector_cosine_ops ` y configurar ` hnsw.ef_search = 100 ` a nivel sesión, el default de 40 sacrifica demasiado recall para la mayoría de los case es RAG.\n2. **Secreto de cuantización:** La cuantización binaria en Qdrant con rescoring te da el 95% del recall de precisión completa con 32x menos memoria. Configurar ` always_ram: true ` para el índice de rescoring.\n3. **Gotcha de Pinecone:** Los índices serverless tienen una penalidad de cold-start de 200-500ms en la primera query después de idle. Si la latencia importa, mantener una query heartbeat corriendo cada 30 segundos.\n4. **Truco de costos:** Para datasets bajo 500K vectores, pgvector en una instancia RDS ` db.r7g.large ` supera a toda base vectorial managed en precio y latencia. No complicarse.\n\n- vector-databases\n- pgvector\n- qdrant\n- pinecone\n- weaviate\n- rag\n- embeddings\n- hnsw\n- ai\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#title"},{"level":2,"text":"El Setup de Test","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#el-setup-de-test"},{"level":2,"text":"Números Crudos: Latencia y Throughput","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#nmeros-crudos-latencia-y-throughput"},{"level":3,"text":"Latencia de Query (10K queries, ms)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#latencia-de-query-10k-queries-ms"},{"level":3,"text":"Throughput (queries/segundo, 100 conexiones concurrentes)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#throughput-queriessegundo-100-conexiones-concurrentes"},{"level":2,"text":"HNSW vs IVF: Cuándo Gana Cada Uno","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#hnsw-vs-ivf-cundo-gana-cada-uno"},{"level":3,"text":"HNSW (Hierarchical Navigable Small World)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#hnsw-hierarchical-navigable-small-world"},{"level":3,"text":"IVF-Flat (Inverted File con cuantización Flat)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#ivf-flat-inverted-file-con-cuantizacin-flat"},{"level":3,"text":"Recomendación","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#recomendacin"},{"level":2,"text":"Cuantización: El Tradeoff de Memoria vs Calidad","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#cuantizacin-el-tradeoff-de-memoria-vs-calidad"},{"level":3,"text":"pgvector: halfvec (float16)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#pgvector-halfvec-float16"},{"level":3,"text":"Qdrant: Cuantización Binaria con Rescoring","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#qdrant-cuantizacin-binaria-con-rescoring"},{"level":2,"text":"La Pregunta de la Búsqueda Híbrida","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#la-pregunta-de-la-bsqueda-hbrida"},{"level":3,"text":"pgvector: La Ventaja Injusta","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#pgvector-la-ventaja-injusta"},{"level":3,"text":"Weaviate: Híbrido Built-in","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#weaviate-hbrido-built-in"},{"level":2,"text":"Análisis de Costos (La Parte Que Decide)","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#anlisis-de-costos-la-parte-que-decide"},{"level":2,"text":"Recomendaciones Prácticas","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#recomendaciones-prcticas"},{"level":2,"text":"La Verdad Incómoda","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#la-verdad-incmoda"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#questions"},{"level":3,"text":"¿Debería usar una base de datos vectorial dedicada o simplemente pgvector?","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-1"},{"level":3,"text":"¿Qué dimensión de embedding debería usar?","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-2"},{"level":3,"text":"¿Cuánto degrada la calidad de búsqueda vectorial con la cuantización?","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#article-tips"}],"sections":[{"heading":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","level":1,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone","content":"AI/ML"},{"heading":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","level":1,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#title","content":"2025-12-029 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/vector-databases-pgvector-qdrant-pinecone>)"},{"heading":"El Setup de Test","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#el-setup-de-test","content":"**Dataset**: 2.3M chunks de documentos de una base de conocimiento de soporte al cliente. Tamaño promedio de chunk: 512 tokens. Embeddeado con ` text-embedding-3-small ` (1536 dimensiones).\n\n**Queries**: 10,000 queries reales de usuarios recolectadas de logs de producción (anonimizadas). Mix de cortas (\"resetear contraseña\"), medianas (\"cómo configurar SSO con Azure AD\"), y largas (\"nuestro equipo está migrando de on-premise a cloud y necesitamos entender las implicaciones de residencia de datos para cumplimiento GDPR\").\n\n**Hardware**:\n\n- pgvector: RDS ` db.r7g.xlarge ` (4 vCPU, 32GB RAM), PostgreSQL 16 con pgvector 0.8\n- Qdrant: cluster de 3 nodos en ` c7g.xlarge ` (4 vCPU, 8GB RAM cada uno), Qdrant 1.13\n- Pinecone: Serverless (Standard), us-east-1\n- Weaviate: cluster de 3 nodos en ` c7g.xlarge `, Weaviate 1.28\n\n**Búsqueda**: Top-10 vecinos más cercanos, similaridad coseno, con filtro de metadata (categoría = valor específico, reduciendo candidatos en ~80%)."},{"heading":"Números Crudos: Latencia y Throughput","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#nmeros-crudos-latencia-y-throughput","content":""},{"heading":"Latencia de Query (10K queries, ms)","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#latencia-de-query-10k-queries-ms","content":"| Base de datos | p50 | p95 | p99 | p99.9 |\n| --- | --- | --- | --- | --- |\n| pgvector (HNSW) | 8.2 | 14.1 | 22.3 | 41.7 |\n| pgvector (IVF) | 12.4 | 24.8 | 38.1 | 67.2 |\n| Qdrant | 3.1 | 5.8 | 8.4 | 14.2 |\n| Pinecone Serverless | 18.4 | 32.1 | 48.7 | 142.3 |\n| Weaviate | 5.7 | 11.2 | 18.9 | 33.4 |\n\nQdrant gana en latencia cruda, y no es ni cerca. Su engine basado en Rust con almacenamiento memory-mapped es genuinamente rápido. Pero observar el p99.9 de Pinecone, ese es 142ms de cola son el cold start serverless afectando el rendimiento. Para aplicaciones interactivas, esa cola es un problema.\n\npgvector con HNSW es sorprendentemente competitivo. Con 8.2ms de p50, es suficientemente rápido para cualquier aplicación RAG. La brecha se amplía en la cola, pero para la mayoría de los case es de uso, es más que adecuado."},{"heading":"Throughput (queries/segundo, 100 conexiones concurrentes)","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#throughput-queriessegundo-100-conexiones-concurrentes","content":"| Base de datos | QPS (sin filtro) | QPS (con filtro) | Delta |\n| --- | --- | --- | --- |\n| pgvector (HNSW) | 2,840 | 2,120 | -25.4% |\n| Qdrant | 8,420 | 7,180 | -14.7% |\n| Pinecone | 1,200 | 980 | -18.3% |\n| Weaviate | 4,100 | 3,250 | -20.7% |\n\nLa diferencia de performance con filtrado es reveladora. pgvector pierde 25% de throughput con filtros porque los aplica post-búsqueda HNSW (una limitación conocida). Qdrant integra el filtrado en el algoritmo de búsqueda, así que la penalidad es menor. Weaviate cae en algún punto intermedio.\n\nEl techo de throughput de Pinecone es notablemente más bajo de lo que se esperaría para un servicio managed. La arquitectura serverless prioriza optimización de costo por query sobre throughput crudo."},{"heading":"HNSW vs IVF: Cuándo Gana Cada Uno","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#hnsw-vs-ivf-cundo-gana-cada-uno","content":"pgvector 0.8 soporta tanto índices HNSW como IVF-Flat. La elección importa más de lo que la mayoría cree."},{"heading":"HNSW (Hierarchical Navigable Small World)","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#hnsw-hierarchical-navigable-small-world","content":"```sql\nCREATE INDEX ON documents\nUSING hnsw (embedding vector_cosine_ops)\nWITH (m = 16, ef_construction = 256);\n\n-- Al momento de la query\nSET hnsw.ef_search = 100;\n```\n\n**Pros**: Queries rápidas, alto recall, sin paso de entrenamiento **Contras**: Alto uso de memoria (~1.5x los datos de vectores), builds de índice lentos\n\nTiempo de build HNSW para 2.3M vectores a 1536 dimensiones: **47 minutos** en nuestra instancia RDS. Uso de memoria: **14.2GB** solo para el índice."},{"heading":"IVF-Flat (Inverted File con cuantización Flat)","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#ivf-flat-inverted-file-con-cuantizacin-flat","content":"```sql\nCREATE INDEX ON documents\nUSING ivfflat (embedding vector_cosine_ops)\nWITH (lists = 1500);\n\n-- Al momento de la query\nSET ivfflat.probes = 40;\n```\n\n**Pros**: Menor uso de memoria (~0.3x), builds de índice más rápidos **Contras**: Requiere entrenamiento (el parámetro lists necesita tuning), menor recall a la misma latencia\n\nTiempo de build IVF: **12 minutos**. Memoria: **4.1GB**. Pero el recall a la misma latencia fue 91.2% vs 97.8% de HNSW."},{"heading":"Recomendación","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#recomendacin","content":"Usar HNSW a menos que la memoria sea la restricción principal. La diferencia de recall (97.8% vs 91.2%) significa que por cada 100 queries, IVF se pierde ~7 resultados relevantes que HNSW encuentra. En un pipeline RAG, ese es chunks perdidos impactan directamente la calidad de las respuestas."},{"heading":"Cuantización: El Tradeoff de Memoria vs Calidad","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#cuantizacin-el-tradeoff-de-memoria-vs-calidad","content":"Con 2.3M vectores a 1536 dimensiones (float32), los datos crudos de vectores son aproximadamente **13.4GB**. La cuantización reduce esto dramáticamente:"},{"heading":"pgvector: halfvec (float16)","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#pgvector-halfvec-float16","content":"```sql\n-- pgvector 0.8 soporta halfvec nativamente\nALTER TABLE documents\n ALTER COLUMN embedding TYPE halfvec(1536);\n\nCREATE INDEX ON documents\nUSING hnsw (embedding halfvec_cosine_ops);\n```\n\nReducción de memoria: 50%. Impacto en recall: **-0.8%** (despreciable). Esto es un decisión evidente para usuarios de pgvector."},{"heading":"Qdrant: Cuantización Binaria con Rescoring","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#qdrant-cuantizacin-binaria-con-rescoring","content":"```json\n{\n \"collection_name\": \"documents\",\n \"vectors\": {\n \"size\": 1536,\n \"distance\": \"Cosine\",\n \"quantization_config\": {\n \"binary\": {\n \"always_ram\": true\n }\n }\n }\n}\n```\n\nLa cuantización binaria reduce cada float32 a un solo bit. 32x de reducción de memoria. Pero el recall crudo baja a ~85%. El truco es el **rescoring**: Qdrant primero busca en el índice binario para obtener un conjunto de candidatos (digamos, top-100), después re-evalúa ese es candidatos contra los vectores de precisión completa. Recall final: **94.7%** con una fracción de la memoria.\n\nEn las pruebas de benchmark:\n\n| Modo Qdrant | Memoria | Latencia p50 | Recall@10 |\n| --- | --- | --- | --- |\n| Precisión completa | 14.8GB | 3.1ms | 98.2% |\n| Binario (sin rescore) | 0.46GB | 1.2ms | 84.9% |\n| Binario + rescore 100 | 0.46GB + 14.8GB disco | 4.8ms | 94.7% |\n| Escalar (int8) | 3.7GB | 2.8ms | 96.1% |\n\nLa cuantización escalar (int8) es el punto dulce para la mayoría: 75% de reducción de memoria con solo 2.1% de pérdida de recall."},{"heading":"La Pregunta de la Búsqueda Híbrida","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#la-pregunta-de-la-bsqueda-hbrida","content":"Los pipelines RAG reales no hacen solo búsqueda vectorial. Necesitás matching de keywords, filtrado de metadata, y muchas veces ambos combinados."},{"heading":"pgvector: La Ventaja Injusta","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#pgvector-la-ventaja-injusta","content":"```sql\nWITH vector_results AS (\n SELECT id, content,\n 1 - (embedding <=> $1::vector) AS vector_score\n FROM documents\n WHERE category = $2\n ORDER BY embedding <=> $1::vector\n LIMIT 20\n),\ntext_results AS (\n SELECT id, content,\n ts_rank(search_vector, plainto_tsquery($3)) AS text_score\n FROM documents\n WHERE category = $2\n AND search_vector @@ plainto_tsquery($3)\n LIMIT 20\n)\nSELECT COALESCE(v.id, t.id) AS id,\n COALESCE(v.content, t.content) AS content,\n COALESCE(v.vector_score, 0) * 0.7 +\n COALESCE(t.text_score, 0) * 0.3 AS combined_score\nFROM vector_results v\nFULL OUTER JOIN text_results t ON v.id = t.id\nORDER BY combined_score DESC\nLIMIT 10;\n```\n\nEsta es la característica más destacada de pgvector: búsqueda híbrida en una sola query, con todo el poder del query planner de PostgreSQL. Sin orquestación externa, sin índice de keywords separado, sin fusión de resultados en código de aplicación."},{"heading":"Weaviate: Híbrido Built-in","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#weaviate-hbrido-built-in","content":"```graphql\n{\n Get {\n Document(\n hybrid: {\n query: \"configuración SSO Azure AD\"\n alpha: 0.7\n fusionType: relativeScoreFusion\n }\n where: {\n path: [\"category\"]\n operator: Equal\n valueText: \"authentication\"\n }\n limit: 10\n ) {\n content\n _additional { score }\n }\n }\n}\n```\n\nWeaviate tiene la mejor historia de búsqueda híbrida entre las bases vectoriales dedicadas. El parámetro ` alpha ` controla el peso vector vs keyword."},{"heading":"Análisis de Costos (La Parte Que Decide)","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#anlisis-de-costos-la-parte-que-decide","content":"Para 2.3M vectores a 1536 dimensiones, corriendo 24/7:\n\n| Base de datos | Costo Mensual | Notas |\n| --- | --- | --- |\n| pgvector (RDS r7g.xlarge) | $412 | Incluye cómputo + almacenamiento |\n| pgvector (Neon Pro) | $69-190 | Escala a cero, pago por query |\n| pgvector (Supabase Pro) | $75-200 | Incluye otras features de Postgres |\n| Qdrant Cloud (3 nodos) | $720 | Cluster dedicado |\n| Qdrant (self-hosted EC2) | $390 | 3x c7g.xlarge |\n| Pinecone Serverless | $280-650 | Depende del volumen de queries |\n| Weaviate Cloud | $580 | Managed 3 nodos |\n\npgvector en [Neon](<https://neon.com/>) o [Supabase](<https://supabase.com/>) es absurdamente barato para workloads chicos a medianos. Y como es solo Postgres, no se está pagando un servicio separado, tus vectores viven al lado de tus datos relacionales.\n\nPara workloads de alto throughput (\\>1000 QPS sostenido), Qdrant self-hosted en instancias ARM es el ganador en relación precio-performance.\n\nEl pricing serverless de Pinecone es atractivo a volúmenes bajos pero escala de forma impredecible. En un caso, los patrones de queries cambiaron y la factura saltó 2.3x."},{"heading":"Recomendaciones Prácticas","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#recomendaciones-prcticas","content":"**Para la mayoría de startups y MVPs**: pgvector en Supabase o Neon. Teners una base de datos vectorial y una base relacional en una. La búsqueda híbrida funciona de una. La latencia es suficientemente buena. Siempre es posible migrar después si lo superás, y en la práctica, la mayoría de los productos nunca lo harán.\n\n**Para producción de alto throughput y sensible a latencia**: Qdrant. El engine en Rust es genuinamente más rápido, las opciones de cuantización te dan control fino sobre el tradeoff memoria/recall, y el filtrado está bien integrado. Self-hostealo en instancias Graviton para la mejor relación precio-rendimiento.\n\n**Para equipos que quieren todo managed y no les importa el costo**: Pinecone. Funciona, es simple, y no teners que pensar en infraestructura. Solo sepa que se está pagando un premium por esa simplicidad, y los cold starts serverless resultarán problemáticos.\n\n**Para aplicaciones heavy en búsqueda híbrida**: Weaviate si se desea una DB vectorial dedicada, pgvector si se desea la flexibilidad de SQL."},{"heading":"La Verdad Incómoda","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#la-verdad-incmoda","content":"Aquí va lo que nadie en el espacio de bases vectoriales quiere admitir: para el 90% de las aplicaciones RAG, pgvector es suficiente. Las bases vectoriales dedicadas son más rápidas, pero \"más rápido\" significa 3ms vs 8ms, ambas son invisibles para el usuario final que está esperando 800ms a que el LLM genere una respuesta.\n\nEl diferenciador real es a escala (\\>10M vectores), a throughput extremo (\\>5000 QPS), o cuando se necesita latencia p99 sub-5ms para aplicaciones en tiempo real. Si esa es la situación, Qdrant o Weaviate valen la complejidad operacional. Si no, y ser honesto sobre si lo es, simplemente utilizar pgvector y dedicar tu tiempo de ingeniería a lo que realmente mueve la aguja: mejores estrategias de chunking, mejores prompts, y mejor evaluación.\n\nLa elección aburrida muchas veces es la correcta."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#questions","content":""},{"heading":"¿Debería usar una base de datos vectorial dedicada o simplemente pgvector?","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-1","content":"Para la mayoría de las aplicaciones bajo 5M de vectores, pgvector es la elección correcta, evitás complejidad operacional y es posible hacer queries híbridas joineando vectores con datos relacionales. Arriba de 10M de vectores o si se necesita latencia p99 sub-10ms, las bases vectoriales dedicadas empiezan a justificar su complejidad."},{"heading":"¿Qué dimensión de embedding debería usar?","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-2","content":"Para la mayoría de aplicaciones RAG, 768 o 1024 dimensiones de un modelo como text-embedding-3-small es el punto dulce. Ir a 1536 o 3072 dimensiones rara vez mejora la calidad de retrieval lo suficiente para justificar el costo 2-4x en almacenamiento y latencia."},{"heading":"¿Cuánto degrada la calidad de búsqueda vectorial con la cuantización?","level":3,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#question-3","content":"Con cuantización escalar (float32 a int8), el recall baja 1-3%. Con cuantización binaria más rescoring, el recall baja solo 2-5% mientras reduce la memoria 32x. La cuantización de producto puede perder 5-10% de recall pero ahorra más espacio."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#article-tips","content":"1. **Win de pgvector:** Utilizar índices ` HNSW ` con ` vector_cosine_ops ` y configurar ` hnsw.ef_search = 100 ` a nivel sesión, el default de 40 sacrifica demasiado recall para la mayoría de los case es RAG.\n2. **Secreto de cuantización:** La cuantización binaria en Qdrant con rescoring te da el 95% del recall de precisión completa con 32x menos memoria. Configurar ` always_ram: true ` para el índice de rescoring.\n3. **Gotcha de Pinecone:** Los índices serverless tienen una penalidad de cold-start de 200-500ms en la primera query después de idle. Si la latencia importa, mantener una query heartbeat corriendo cada 30 segundos.\n4. **Truco de costos:** Para datasets bajo 500K vectores, pgvector en una instancia RDS ` db.r7g.large ` supera a toda base vectorial managed en precio y latencia. No complicarse.\n\n- vector-databases\n- pgvector\n- qdrant\n- pinecone\n- weaviate\n- rag\n- embeddings\n- hnsw\n- ai\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/vector-databases-pgvector-qdrant-pinecone"},{"text":"Neon","url":"https://neon.com/"},{"text":"Supabase","url":"https://supabase.com/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone"},"headline":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","description":"Benchmarks honestos comparando pgvector 0.8, Qdrant, Pinecone y Weaviate para un pipeline RAG real. Indexación HNSW vs IVF, tradeoffs de cuantización, latencia a escala, y recomendaciones prácticas para diferentes case es de uso.","datePublished":"2025-12-02","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://lucioduran.com/favicons/og-default.png","url":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"AI/ML","keywords":"vector-databases, pgvector, qdrant, pinecone, weaviate, rag, embeddings, hnsw, ai","wordCount":1495,"timeRequired":"PT9M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/vector-databases-pgvector-qdrant-pinecone"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Bases de Datos Vectoriales Comparadas: Ejecutando el Mismo Pipeline RAG en pgvector, Qdrant, Pinecone y Weaviate","item":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Debería usar una base de datos vectorial dedicada o simplemente pgvector?","acceptedAnswer":{"@type":"Answer","text":"Para la mayoría de las aplicaciones bajo 5M de vectores, pgvector es la elección correcta, evitás complejidad operacional y es posible hacer queries híbridas joineando vectores con datos relacionales. Arriba de 10M de vectores o si se necesita latencia p99 sub-10ms, las bases vectoriales dedicadas empiezan a justificar su complejidad."}},{"@type":"Question","name":"¿Qué dimensión de embedding debería usar?","acceptedAnswer":{"@type":"Answer","text":"Para la mayoría de aplicaciones RAG, 768 o 1024 dimensiones de un modelo como text-embedding-3-small es el punto dulce. Ir a 1536 o 3072 dimensiones rara vez mejora la calidad de retrieval lo suficiente para justificar el costo 2-4x en almacenamiento y latencia."}},{"@type":"Question","name":"¿Cuánto degrada la calidad de búsqueda vectorial con la cuantización?","acceptedAnswer":{"@type":"Answer","text":"Con cuantización escalar (float32 a int8), el recall baja 1-3%. Con cuantización binaria más rescoring, el recall baja solo 2-5% mientras reduce la memoria 32x. La cuantización de producto puede perder 5-10% de recall pero ahorra más espacio."}}]}]}],"contentHash":"f2cecca2ac72b5ac5ef53b916a937dcd26664098597698e1e483035a4f86b8a7","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/vector-databases-pgvector-qdrant-pinecone","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":71713,"contentBytes":12966}}