Postgres, MongoDB y la nueva ola de vector DBs: cómo elegir base de datos en 2024

Cada semana llega un cliente con la misma pregunta. "Estamos por meter búsqueda semántica (o RAG, o un asistente IA) y nos están vendiendo Pinecone. ¿Vale la pena? ¿O nos quedamos con Postgres?". La respuesta corta es: depende del patrón de acceso, no de la moda. La respuesta larga es lo que escribimos abajo.

En 2024 el panorama se simplificó más de lo que parece. Postgres con la extensión pgvector y MongoDB con Atlas Vector Search ya cubren entre el 70% y el 80% de los casos enterprise. Las bases de datos vector-first (Pinecone, Weaviate, Qdrant, Chroma) se ganaron un nicho legítimo, pero ese nicho es más estrecho de lo que el marketing sugiere.

El estado del arte a abril de 2024

Postgres 16 + pgvector 0.7 trae soporte nativo para índices HNSW, búsqueda por similitud de coseno, L2 y producto interno, y se integra de forma natural con tablas relacionales. Es decir: puedes hacer un JOIN entre embeddings y datos transaccionales en una sola query. Esa simplicidad operativa es invaluable.

MongoDB 7 + Atlas Vector Search llegó a GA en 2023 y maduró durante 2024. Permite mezclar búsquedas semánticas con filtros de documentos en una sola operación, y aprovecha la replicación y sharding existente del cluster.

Pinecone, Weaviate, Qdrant y Chroma son bases de datos diseñadas desde cero para vectores. Ofrecen latencias bajas a escalas de cientos de millones de vectores, particionamiento horizontal nativo y features específicas (filtrado híbrido, multi-tenancy serio, payload arbitrario).

Cuándo gana cada uno

Postgres + pgvector

Es la opción correcta cuando ya tienes Postgres en producción, los embeddings están relacionados con tablas existentes (productos, clientes, documentos), y tu volumen de vectores está por debajo de los 10 millones.

Ventajas reales: una sola base que mantener, transacciones ACID sobre embeddings y datos al mismo tiempo, ecosistema masivo de tooling (psql, ORMs, herramientas de backup, monitoreo). El costo marginal es prácticamente cero si ya pagas tu instancia.

Lo que vemos en clientes mexicanos medianos: catálogos de productos con búsqueda semántica, sistemas de tickets internos con sugerencias automáticas, RAG sobre documentación corporativa. Todo eso entra cómodo en pgvector con índice HNSW bien tuneado.

Donde empieza a apretar: cuando pasas de 50 millones de vectores y necesitas rebuilds rápidos del índice, o cuando tienes patrones de query muy heterogéneos que pelean por el cache de Postgres.

MongoDB Atlas Vector Search

La opción natural si tu stack ya está en MongoDB y manejas documentos con estructura variable. La búsqueda vectorial vive al lado de tus colecciones, sin tener que sincronizar dos sistemas.

Funciona muy bien para casos donde el embedding va junto con metadata rica y heterogénea (descripciones, atributos dinámicos, jerarquías). El operador $vectorSearch permite combinar similitud con filtros tradicionales en un solo pipeline.

Limitación que vale conocer: Atlas Vector Search está atado a Atlas. Si corres MongoDB self-hosted, no tienes esta función nativa y tendrías que armar algo con extensiones de terceros. Para empresas que ya pagan Atlas, no hay fricción.

Vector-first DBs (Pinecone, Weaviate, Qdrant, Chroma)

Tienen sentido en tres escenarios concretos:

Escala muy alta. Cuando trabajas con cientos de millones a miles de millones de vectores y necesitas latencias consistentes por debajo de 50 ms. Aquí Pinecone y Qdrant brillan por arquitectura distribuida nativa.

Multi-tenancy serio. Si construyes un SaaS donde cada cliente tiene su propio namespace de vectores con aislamiento estricto, las primitivas de las vector DBs son más limpias que armar el mismo aislamiento sobre Postgres.

Producto donde la búsqueda semántica es el corazón. Si tu negocio entero es "encontrar lo más parecido", justifica una base optimizada para eso. Si es una feature más entre otras, no.

Pinecone es el más fácil de operar (managed puro). Weaviate tiene buen ecosistema open-source y módulos de vectorización integrados. Qdrant brilla en eficiencia de memoria y self-hosted. Chroma es excelente para prototipos y desarrollo local, pero todavía joven para cargas pesadas en producción.

Costos: el factor que casi nadie mide bien

Una comparación rápida con un caso típico que vemos: 5 millones de embeddings de 1,536 dimensiones (OpenAI text-embedding-3-small), unas 50 mil queries diarias.

• Postgres en RDS o self-hosted: entre $200 y $500 USD al mes si ya tienes la instancia. Costo marginal de pgvector: cero.
• MongoDB Atlas con Vector Search en cluster M30: alrededor de $700 a $1,200 USD al mes.
• Pinecone serverless: entre $300 y $800 USD al mes según patrón de queries.
• Qdrant self-hosted en una VM mediana: $150 a $300 USD al mes en infraestructura, más el costo operativo de mantenerlo.

Las diferencias en dólares no son enormes, pero el costo operativo (gente que sabe operar un sistema más) sí lo es. Cada base nueva en tu stack es un punto de mantenimiento, monitoreo, backup y on-call adicional.

Decision framework para empresa mediana

El framework que usamos en ALCA tiene cuatro preguntas en orden:

1. ¿Ya tienes Postgres o MongoDB en producción? Si la respuesta es sí, empieza por extender lo que tienes. La carga operativa de meter una base nueva se justifica solo si las otras tres preguntas también empujan.

2. ¿Cuántos vectores vas a tener en 18 meses? Por debajo de 10 millones, pgvector o Atlas Vector Search son perfectamente capaces. Por arriba de 100 millones, vale la pena evaluar vector-first. La zona gris (10 a 100 millones) depende de patrones de query.

3. ¿La búsqueda semántica es feature o producto? Si es una feature dentro de una aplicación más grande, no metas una base nueva. Si es el producto central, sí justifica especialización.

4. ¿Tienes el equipo para operar una base más? Una vector DB nueva implica monitoreo, backups, parches, on-call, integración con CI/CD. Si tu equipo de plataforma está al límite, quédate con lo que ya operas.

Cuándo migrar (y cuándo no)

Migrar es caro y rara vez justificado en el primer año. Recomendamos evaluar migración solo cuando aparece al menos uno de estos síntomas:

• Latencias p95 consistentemente arriba de 200 ms en queries vectoriales.
• Indexación que toma horas y bloquea operaciones.
• Costo de infraestructura que crece más rápido que el negocio.
• Patrones de multi-tenancy que ya no entran en el modelo actual.

Si ninguno aplica, quedarte donde estás es la decisión correcta. La mejor base de datos suele ser la que ya conoces bien.

Lo que vamos a ver en lo que queda de 2024

Tres tendencias que vale la pena seguir: Postgres seguirá ganando terreno con mejoras a pgvector (índices más eficientes, mejor integración con extensiones de IA), MongoDB profundizará la integración con Atlas Search híbrido, y las vector-first DBs van a competir más en pricing serverless que en features.

La buena noticia para empresas medianas mexicanas es que ya no hay que pagar overhead de complejidad para tener búsqueda semántica decente. La extensión pgvector en una instancia que ya tienes resuelve el primer 80%. El otro 20% es un problema bonito de tener.

---

¿Quieres una segunda opinión sobre tu elección de base de datos? Conversemos. Agenda una sesión técnica de 45 minutos y revisamos juntos tu caso concreto.