pgvector o Pinecone: triplicar QPS puede costar 4,8 veces más

Una prueba de Markaicode con un millón de vectores float32 de 768 dimensiones atribuye al pod Pinecone s1.x1 1.200 QPS frente a 400 de pgvector 0.7.0 con IVFFlat en PostgreSQL 16, con recall cercano al 99 %, medianas de latencia de 8 y 20 ms y un coste calculado por consulta 4,8 veces mayor para Pinecone: 0,12 frente a 0,025 dólares por mil consultas.

Si una aplicación RAG ya guarda sus documentos en PostgreSQL, conservar la búsqueda con pgvector tiene sentido mientras cumpla el recall y la latencia requeridos, incluidos los filtros. Pinecone merece una prueba cuando el crecimiento, las actualizaciones o el trabajo de mantener el índice pesan más que operar un servicio adicional. La proporción de coste publicada describe las configuraciones ensayadas, no una factura aplicable a cualquier despliegue.

Qué permite concluir la prueba

El resultado enfrenta un pod con una instancia concreta de PostgreSQL y un índice IVFFlat, no todas las opciones de ambos productos. La menor latencia de Pinecone acompaña al mayor caudal en esa carga sintética; una aplicación con documentos desiguales, filtros por permisos o ráfagas de consultas puede producir otra relación. También cambia la comparación si pgvector utiliza HNSW o si Pinecone se contrata con una arquitectura distinta del pod ensayado.

Hay una dificultad para reproducir el resultado: la metodología mezcla IVFFlat con ef_search, parámetro de HNSW. Además, describe consultas secuenciales sin explicar la concurrencia necesaria para conciliar el caudal declarado con la latencia mediana. Estas inconsistencias no permiten tratar la diferencia de QPS como una ventaja general de Pinecone. El coste normalizado tampoco equivale a una tarifa: procede de capacidad amortizada y no ofrece los importes horarios de partida necesarios para rehacer toda la cuenta.

El tamaño del corpus da otra perspectiva. Solo los componentes de un millón de vectores como los ensayados ocupan unos 3,07 GB; con diez millones serían unos 30,72 GB, antes de índices, identificadores y metadatos. Es una cuenta de almacenamiento bruto, no una predicción de memoria residente ni de precio. Al crecer los datos pueden cambiar el índice viable, el tiempo de construcción y la instancia necesaria, aunque cada consulta siga solicitando la misma cantidad de resultados.

El índice cambia velocidad, memoria y mantenimiento

La documentación de pgvector distingue búsqueda exacta, HNSW e IVFFlat: HNSW mejora la relación entre velocidad y recall frente a IVFFlat, pero tarda más en construirse y usa más memoria; IVFFlat se construye antes y ocupa menos, aunque requiere ajustar listas y sondas, y desde la versión 0.8.0 las exploraciones iterativas pueden ampliar una búsqueda filtrada hasta un límite.

Por eso, comparar el pod con IVFFlat deja abierta una decisión importante para quien use PostgreSQL. HNSW puede entregar una calidad de recuperación equivalente con otra latencia y otro consumo de memoria; IVFFlat puede resultar atractivo si construir y alojar el índice es la restricción principal. En ambos casos, aumentar los candidatos examinados suele mejorar el recall a cambio de trabajo por consulta. La opción adecuada depende del espacio que deje la base para sus tareas relacionales, no solo de la velocidad de una búsqueda aislada.

Las inserciones, cambios y borrados también forman parte de la carga. Un índice construido sobre un conjunto estable no describe necesariamente la recuperación tras semanas de modificaciones, ni cuánto tiempo ocuparán las tareas de mantenimiento. Para RAG, importa medir cuándo aparece el documento nuevo en los resultados y si la calidad de las respuestas cambia después de actualizar el corpus.

Los filtros pueden invertir la elección

En una búsqueda aproximada de pgvector, el filtro puede aplicarse después de explorar candidatos del índice. Si pocos candidatos cumplen la condición, la consulta puede devolver menos resultados de los solicitados aunque existan más filas válidas. Las exploraciones iterativas continúan buscando hasta obtener suficientes coincidencias o alcanzar su límite; los índices sobre columnas filtradas, los índices parciales y las particiones ofrecen otras rutas con costes distintos de memoria y mantenimiento.

La selectividad importa más que la presencia de un filtro en abstracto. Una categoría amplia puede dejar suficientes candidatos en la primera exploración, mientras un permiso o un inquilino con pocos documentos puede exigir mucho más trabajo. Por eso conviene registrar tanto el tiempo como el número de resultados entregados: dos sistemas pueden responder con igual rapidez y proporcionar cantidades distintas de contexto útil al generador.

Quién conserva el control operativo

La comparación de Pinecone reconoce que mantener los vectores en PostgreSQL permite reutilizar copias de seguridad, recuperación a un punto temporal, replicación y controles de acceso, mientras su servicio evita al equipo dimensionar y mantener el índice vectorial.

Si la recuperación debe combinar vectores con filas transaccionales y reglas de acceso de la misma base, pgvector conserva esa operación en un solo sistema. Con Pinecone, PostgreSQL puede seguir siendo el registro principal, pero la aplicación necesita sincronizar vectores y metadatos y recorrer otra API. Esa separación desplaza trabajo de administración del índice hacia la integración: hay que observar retrasos de actualización, fallos de sincronización y latencia de extremo a extremo.

Coste por consulta frente a factura mensual

Las reglas de facturación de Pinecone indican que serverless mide lecturas, escrituras, almacenamiento y salida de datos, con cargos separados para algunas operaciones adicionales. La cifra normalizada del pod ensayado no debe trasladarse a ese modelo. PostgreSQL, por su parte, requiere pagar capacidad y almacenamiento aprovisionados durante el periodo en que permanezcan disponibles, incluso cuando recibe pocas búsquedas.

Como ejercicio puramente aritmético sobre las cifras normalizadas de la prueba, un millón de consultas representaría 120 dólares frente a 25. Esos importes no predicen una factura: faltan ocupación real, escrituras, almacenamiento, capacidad reservada y trabajo operativo. Una carga sostenida aprovecha de otra forma una instancia ya pagada que una carga intermitente. Comparar presupuestos exige el mismo periodo, el mismo volumen de datos y un nivel semejante de recuperación.

Una comparación repetible para el RAG propio

La prueba decisiva utiliza los documentos, el modelo de embeddings y las consultas de la aplicación. Primero se fija un recall mínimo frente a búsqueda exacta; después se comparan QPS y latencia de configuraciones que alcanzan ese umbral. Así, una mejora de velocidad no se compra a costa de perder pasajes necesarios para responder.

1. Medir el corpus actual y el previsto: dimensiones, metadatos, distribución por inquilino y frecuencia de altas, cambios y borrados.
2. Separar consultas sin filtro, filtros habituales y filtros muy selectivos. Registrar cuántos resultados válidos devuelve cada una, además de su latencia.
3. Probar pgvector con HNSW y, si corresponde, IVFFlat; anotar versión, parámetros, memoria, tiempo de construcción y plan de PostgreSQL. Identificar con precisión la arquitectura contratada en Pinecone.
4. Medir caudal a distintos niveles de concurrencia, latencia mediana y de cola desde la aplicación. Repetir las mediciones después de actualizar el índice.
5. Convertir lecturas, escrituras, almacenamiento y capacidad utilizados en costes del mismo periodo, incorporando el mantenimiento de PostgreSQL y la sincronización con Pinecone.

Si pgvector alcanza el recall exigido, completa las búsquedas filtradas y mantiene la latencia objetivo con la capacidad disponible, conservarlo evita añadir otra ruta de datos. Si cumplir esas condiciones obliga a ampliar mucho la base o a dedicar demasiado trabajo al índice, el servicio gestionado debe compararse con ese coste completo, no con una proporción obtenida en una sola prueba.

Lee también:

• Make o Zapier: un filtro temprano puede invertir el coste del flujo
• Skool o Mighty Networks: una app propia puede costar más que la comunidad
• Stripe o PayPal en España: la devolución puede costar más que la venta