Argumentos en contra de PGVector

 (alex-jacobs.com)
9 puntos por GN⁺ 2025-11-04 | 5 comentarios | Compartir por WhatsApp
  • La extensión de Postgres pgvector permite la búsqueda por similitud de vectores, pero existe una gran brecha entre el nivel de demo y un entorno real de producción
  • Tanto los índices IVFFlat como HNSW tienen ventajas y desventajas claras; en particular, HNSW presenta problemas de uso de memoria de varios GB durante la creación del índice y tiempos de construcción largos
  • La búsqueda en tiempo real y la actualización de índices son estructuralmente difíciles, y con inserciones y actualizaciones continuas se producen contención de locks y degradación del rendimiento
  • Debido a la estrategia de filtrado (Pre/Post) y a las limitaciones del planificador de consultas, aparece un equilibrio inestable entre precisión de búsqueda y velocidad
  • Hay que implementar manualmente funciones que ofrecen las bases de datos vectoriales dedicadas (Pinecone, Weaviate, etc.), lo que al final lleva a mayor complejidad operativa y más costos

Resumen de las limitaciones de pgvector

  • pgvector es una extensión que agrega a Postgres la función de búsqueda por similitud de vectores; funciona bien en demos simples, pero en entornos de producción aparecen problemas de escalabilidad
  • Muchos artículos de blog solo cubren la instalación y ejemplos de consultas sencillas, y casi no mencionan los problemas de rendimiento, memoria y gestión de índices que surgen en operación

El problema de elegir un índice

  • pgvector ofrece dos tipos de índices: IVFFlat y HNSW
    • IVFFlat: estructura basada en clústeres; la creación del índice es rápida, pero la configuración del número de clústeres influye mucho en el rendimiento y la precisión
      • Como no se puede redistribuir entre clústeres, se requiere una reconstrucción periódica del índice
    • HNSW: estructura de grafo multinivel que ofrece precisión y rendimiento consistente, pero durante la creación del índice tiene un uso de memoria muy alto y una velocidad lenta
  • Al crear índices para millones de vectores, es posible usar más de 10 GB de RAM, lo que representa una amenaza directa para la estabilidad de la base de datos de producción

Dificultades de la búsqueda en tiempo real

  • Después de insertar datos nuevos, deberían poder buscarse de inmediato, pero por la estructura de actualización del índice es difícil reflejarlos en tiempo real
    • IVFFlat: los nuevos vectores se agregan a clústeres existentes, y con el tiempo se produce desequilibrio entre clústeres → se necesita reconstrucción periódica
    • HNSW: al insertar, la actualización del grafo provoca contención de locks y carga de memoria
  • Durante la reconstrucción del índice es difícil mantener la consistencia de los datos y garantizar la continuidad del servicio
  • En entornos de producción se necesitan varias estrategias de escape, como tablas de staging, índices dobles, compilación offline y eventual consistency

Limitaciones del filtrado y del planificador de consultas

  • Al combinar la búsqueda vectorial con filtrado por metadatos como status, user_id y category, la elección entre Pre-filter vs Post-filter afecta mucho el rendimiento
    • Pre-filter favorece filtros selectivos, pero puede ser lento cuando hay muchos datos
    • Post-filter es rápido, pero existe la posibilidad de perder resultados después del filtrado
  • El planificador de consultas de Postgres no entiende el modelo de costos de similitud vectorial, y como la información estadística es inexacta, genera planes de ejecución ineficientes
  • Como resultado, se requieren soluciones temporales como CTE, particionamiento y reescritura de consultas, lo que se vuelve ineficiente al escalar

Comparación con bases de datos vectoriales dedicadas

  • Pinecone, Weaviate, OpenSearch k-NN y otras ofrecen de forma nativa selección automática de estrategia de filtrado, búsqueda híbrida, indexación en tiempo real y escalado horizontal
  • En pgvector estas funciones deben implementarse directamente, lo que lleva a complejidad operativa y carga de mantenimiento
  • pgvectorscale de Timescale ofrece StreamingDiskANN, construcción incremental de índices y mejoras en filtrado, pero
    • no es compatible con AWS RDS y además existe la carga de instalar y administrar una extensión adicional

Costos y consideraciones operativas

  • Una base de datos vectorial dedicada puede ser un servicio de pago, pero si se considera el sobreaprovisionamiento de infraestructura Postgres, la gestión de índices y el tiempo de ingeniería, en la práctica puede salir más barata
  • Por ejemplo, Turbopuffer comienza desde $64 al mes y ofrece simplicidad operativa y escalabilidad

Conclusión y recomendaciones

  • pgvector es excelente desde el punto de vista técnico, pero en producción tiene muchas limitaciones
  • Puntos clave a considerar al construir un sistema en producción
    1. La complejidad de la gestión de índices y los altos requisitos de memoria
    2. Las limitaciones del planificador de consultas, que generan ineficiencia en el filtrado
    3. El costo de la indexación en tiempo real y la pérdida de calidad
    4. La simplificación excesiva de muchos artículos de blog
    5. La razón de existir de las bases de datos vectoriales dedicadas y su eficiencia
  • En conclusión, la complejidad operativa supera la simplicidad de integrarlo con Postgres, y para la mayoría de los equipos usar una base de datos vectorial dedicada es la opción más realista

Lecturas relacionadas

5 comentarios

 
kaydash 2025-11-05

Aun así, para consultas compuestas (embeddings + SQL tradicional), no hay nada como pg_vector.
 
yangeok 2025-11-04

Creo que para que el ecosistema esté sano también debe haber muchas refutaciones a las ideas que pretenden servir para todo.
 
ethanhur 2025-11-05

Estoy de acuerdo. Está claro que, para una organización que ya usaba bien PostgreSQL y está empezando con un VectorDB usando un volumen pequeño de datos, pgVector es una excelente opción; pero cuando el tráfico aumenta —especialmente el tráfico de escritura—, parece que el problema que menciona el autor de la publicación original se vuelve un cuello de botella.
 
ndrgrd 2025-11-04

Así es. Nada es perfecto. Creo que puede aceptarse algo como "hay otros asuntos más urgentes", pero no se debería tolerar "el nivel actual ya es suficiente".
 
GN⁺ 2025-11-04
Opinión de Hacker News

  • En Discourse ya usamos pgvector en producción en miles de bases de datos.
    Se usa en la mayoría de las pageviews, y la función Iterative Scans se añadió en la versión 0.8.0 para mejorar los problemas de filtrado pre/post.
    Si se trata de un solo servicio, una base de datos vectorial dedicada quizá sea más fácil, pero no es una solución universal.

    • Usamos quantization de forma intensiva.
      Para almacenamiento usamos halfvec (float de 16 bits) y para índices bit (vectores binarios), con lo que conseguimos tanto ahorro de almacenamiento como rendimiento.
    • En nuestra empresa Halcyon manejamos billones de embeddings, y Postgres no era adecuado para esa escala.
      Usamos Vespa para hacer búsquedas estilo map-reduce a nivel de nodo.
      Para hacer algo parecido en Postgres probablemente harían falta sharding y lógica de aplicación compleja.
      También creemos que el reindexado o la desnormalización de metadatos inevitablemente toman mucho tiempo.
      Aun así, una base de datos vectorial tampoco es una solución mágica, y un sistema como Vespa que admite filtrado relacional es mucho más eficiente.
    • Hay mucha gente usando pgvector en producción.
      Pero iterative scan no es una solución de fondo, sino más bien un parche temporal.
      Hay que entender parámetros como ef_search y max_search_tuples, y el planner no comprende por completo el modelo de costos de la búsqueda vectorial con filtros.
      Al final, la cuestión es si tienes capacidad para tunear tú mismo un query planner inteligente, o si prefieres usar un servicio especializado en eso.
    • También existe el enfoque de hacer el filtrado durante el recorrido del índice.
      El método descrito en este paper de Microsoft está implementado en pgvectorscale de Timescale.
      Este enfoque puede ser más eficiente que el simple filtrado pre/post.
    • Me da curiosidad saber para qué uso es. ¿Será un sistema de búsqueda híbrida que combina palabras clave + vectores?

  • En VectorChord ya resolvimos la mayoría de los problemas de pgvector mencionados en el blog.
    Usamos IVF + quantization para ofrecer actualizaciones 15 veces más rápidas que HNSW de pgvector.
    Con 16 vCPU y 32 GB de memoria podemos indexar 100 millones de vectores de 768 dimensiones en 20 minutos.
    Es posible reindexar sin pérdida de datos con CREATE INDEX CONCURRENTLY.
    También soporta filtrado pre/post y búsqueda híbrida basada en BM25.
    Para más detalles, consulta el blog de VectorChord.

    • Si usan quantization e IVF, me da curiosidad cuál es el nivel real de recall.
    • Tenemos un cliente operando 3 mil millones de vectores con Postgres + VectorChord + sharding.
      Puedes ver el caso en este blog.
    • Evaluamos VectorChord, pero como no es compatible con RDS, no pudimos adoptarlo porque implicaba agregar otro servicio.

  • La construcción de índices consume mucha memoria, pero se puede controlar con maintenance_work_mem.
    La reconstrucción del índice se puede manejar con REINDEX CONCURRENTLY, y las actualizaciones de HNSW son conceptualmente parecidas a las de un B+tree.
    Este artículo da la impresión de que no leyó bien la documentación de Postgres.

    • Pero si limitas maintenance_work_mem, el indexado se vuelve más lento.
      Un B+tree solo toca páginas log H, mientras que HNSW tiene que modificar miles de vectores.
    • Un índice HNSW puede medir desde cientos de GB hasta varios TB.
      Para reconstruirlo hay que asegurar más del doble de la capacidad de la base de datos, y además afecta otras cargas de trabajo.
      REINDEX CONCURRENTLY también toma mucho tiempo.
      Aunque la complejidad de inserción de HNSW sea baja, el costo constante es alto, así que en la práctica sí pesa.
    • Aunque existan ajustes como maintenance_work_mem, es riesgoso ocupar varios GB de RAM durante horas en un entorno productivo.
      REINDEX CONCURRENTLY también usa de 2 a 3 veces más disco y afecta el rendimiento.
      Al final, el punto no es que a Postgres le falten funciones, sino que la complejidad operativa es alta.
      Una base de datos vectorial dedicada maneja estas cosas automáticamente, así que para equipos pequeños puede ser mucho más eficiente.

  • El hecho de que Turbopuffer empiece en USD 64 al mes explica la popularidad de pgvector.
    Si USD 64 te parece caro, usa pgvector; si te parece barato, probablemente ya tengas un caso de uso complejo y una base de datos vectorial dedicada sea más adecuada.

  • Incluso entre clientes de GCP he visto muchos casos usando pgvector HNSW en producción.
    Aun así, solo es realista en escalas de 0 a 10 millones de vectores.
    Hay que considerar ETL, overhead operativo y problemas de consistencia.
    Si necesitas transacciones, búsqueda híbrida y baja latencia, AlloyDB + ScaNN es una mejor opción.
    (Como referencia, yo creé ScaNN en GCP y actualmente lidero AlloyDB Semantic Search).

    • Como AlloyDB no es open source, apunta a otro mercado.

  • Mi principio base es YAGNI.
    Intento reducir al mínimo la cantidad de servicios, y si aparece un problema, entonces agrego algo nuevo.
    Si Postgres basta, lo dejo así; y si no, en ese momento ya sabes exactamente qué necesitas.

    • Pero ese enfoque a menudo sale contraproducente.
      Cosas como escrituras vectoriales en tiempo real o combinar filtros SQL con búsqueda por similitud parecen menores, pero en la práctica son funciones esenciales.
      Cuando la escala crece, esas limitaciones se vuelven críticas.
    • Una vez que eliges una base de datos, es difícil reemplazarla, así que conviene ser cuidadoso desde el principio.

  • Al usar modelos de embeddings vectoriales, hay mucha utilidad incluso sin un dataset masivo.
    Por ejemplo, en casos como búsqueda de documentos o búsqueda de información de productos.
    Yo quiero una interfaz donde escribas documentos como en un sistema de archivos y el índice se actualice automáticamente.
    Por eso servicios como Amazon S3 Vectors(enlace) me parecen interesantes.
    Me da curiosidad conocer experiencias reales de uso.

  • Los problemas mencionados ya se resolvieron, y yo prefiero usar PGVector.
    Si Postgres puede reemplazar a Kafka y procesar 100 mil eventos por segundo, entonces PGVector también puede ser suficiente en lugar de una base de datos vectorial dedicada como Chroma.
    Enlace de referencia

    • Me gustaría saber específicamente qué problemas se resolvieron.

  • La mayoría de los casos de uso de pgvector son datasets pequeños, como un “chatbot basado en documentación técnica”.
    Los datos no cambian con frecuencia y no hay multitenancy, así que también hay menos problemas de filtrado.
    En cambio, Chroma soporta SPANN, SPFresh y búsqueda híbrida, y es completamente open source bajo Apache 2.0.
    Con facturación por uso, incluso puede costar alrededor de 1 dólar al mes.

  • Durante el último año desarrollé Redis Vector Sets para resolver estos problemas.
    Implementa HNSW directamente, lo que permite actualizaciones en tiempo real, y al eliminar datos también libera memoria de inmediato.
    Soporta inserciones de cientos de miles de ops/sec y búsquedas de 50 mil ops/sec.
    Además, soporta quantization de forma nativa, así que también es eficiente en memoria.
    Todo está explicado con detalle en el documento README.
    Actualmente la funcionalidad de replicación también ya fue probada por completo.