Pinecone vs Postgres pgvector: cuándo cada uno tiene sentido

Cuando arranqué ReclamaAI, Pinecone era el default obvio para vector search. Estaba documentado, era serverless, tenía free tier generoso. Un año después, con embeddings reales y queries en producción, me planteé migrar a pgvector para unificar bajo Postgres. Hice la comparación, casi migré, y al final me quedé con Pinecone. Este es el porqué.

Lo que necesita ReclamaAI

Antes de comparar herramientas, vale la pena describir el caso de uso real:

• Decenas de miles de vectores almacenados (chunks de normativa, jurisprudencia y plantillas).
• Cientos de queries diarias, una por cada generación.
• Latencia P95 objetivo: por debajo de 200ms para no ralentizar el flujo del usuario.
• Embeddings dimensionalidad estándar (1536) de OpenAI.
• Cada query trae los top-5 vectores más similares con metadata filtering por tipo de documento.

No es escala absurda. Es perfectamente operable desde cualquiera de las dos opciones.

Pinecone, lo que me da

Pinecone es una base de datos especializada en vectores. Lo que aprecio:

• Latencia muy baja. En mi caso, sin tunear nada, Pinecone se mantiene cómodamente por debajo de mi target. Está optimizado para esto y se nota.
• Sin gestión. No hay índices que mantener, no hay reindex que correr, no hay tuning de HNSW que aprender.
• API simple. Tres métodos: upsert, query, delete. Eso es todo lo que uso. La librería oficial de Node es decente.
• Metadata filtering nativo. Cada vector tiene metadata (tipo de norma, año, jurisdicción), y los filtros se aplican antes de la búsqueda. Es la feature que más uso.

Lo que NO me gusta:

• Es un servicio externo. Otra dependencia, otra factura, otro lugar donde puede caerse.
• Costo a escala. El plan free me cubre 100k vectores y queries ilimitadas. El siguiente escalón empieza en USD 70/mes. Para mi escala actual, free está bien. Para 10x del tamaño, ya es plata.

pgvector, lo que me daría

pgvector es una extensión de Postgres que añade un tipo vector y operadores de similitud. Lo que ganaría:

• Una sola base de datos. Mis vectores vivirían junto a mis documentos, usuarios, jobs. Joins reales entre vectores y filas relacionales sin ETL.
• Costo cero adicional. Mi Neon Postgres ya está pagado, agregar pgvector no cuesta más.
• Backups y migraciones unificados. Cuando hago un dump de la DB, los vectores van incluidos. Cuando rollback de schema, los vectores rollback con todo.
• SQL nativo. Filtros complejos, joins, aggregations. Todo el poder de Postgres aplicado a vectores.

Lo que perdería:

• Latencia. En mi prueba con índice HNSW configurado razonablemente, el P95 quedó casi al límite de mi target. Si crezco, queda por encima.
• Gestión del índice. HNSW requiere parámetros (m, ef_construction, ef_search). El default funciona pero no es óptimo. Tunearlo es tiempo de dev.
• Memoria de Postgres. El índice HNSW vive en RAM para ser rápido. A escalas de decenas de miles de vectores con dimensionalidad 1536, hablamos de cientos de MB. Mi instancia tiene espacio, pero no infinitamente.

El experimento real

Migré los vectores a pgvector en una rama de prueba durante una semana y comparé las mismas queries en ambas bases. La diferencia de latencia fue consistente: Pinecone respondió en aproximadamente la mitad del tiempo de pgvector en P95, con un margen aún mayor en P99.

La diferencia importa pero no es brutal. Para mi caso, pgvector queda justo en el límite del target de latencia. Para casos donde la latencia importa más (search-as-you-type, recomendaciones en tiempo real), Pinecone gana cómodamente.

La decisión: me quedé con Pinecone

Tres razones, en orden de peso:

1. Latencia con headroom. Pinecone me da margen para crecer sin tunear. pgvector ya está cerca del límite. Migrar para ganar nada operacional y perder margen no me convence.
2. Tiempo de mi cabeza. Mantener un índice HNSW óptimo en Postgres es trabajo recurrente. Pinecone es "déjalo y olvídalo". Como solo founder, prefiero pagar USD 70/mes (cuando llegue) que dedicar 4 horas al mes a optimizar índices.
3. Riesgo bajo de migrar después. Si Pinecone sube precios de forma absurda o cambia de modelo, migrar a pgvector me toma 3-4 días con el código actual. La opción de salida existe y es barata. Eso me da tranquilidad para quedarme con la opción cómoda hoy.

Cuándo elegiría pgvector

Si estuvieras empezando desde cero hoy, mi recomendación cambiaría según el caso:

• pgvector si: ya tienes Postgres, tu escala es modesta (<100k vectores), no necesitas latencia <100ms, valoras tener todo en una sola DB, y tu equipo está cómodo con SQL.
• Pinecone si: tu escala va a crecer rápido, necesitas latencia ultra baja, no quieres gestionar índices, y prefieres pagar por un servicio especializado en lugar de aprender a tunear pgvector.

No hay una respuesta correcta. Hay un trade-off entre simplicidad operativa (Pinecone) y control unificado (pgvector). Para ReclamaAI, hoy, gana la simplicidad operativa. Mañana puede cambiar.