Postgres, MongoDB y la primera ola seria de vector DBs: cómo elegir base de datos en 2023
La conversación de bases de datos en empresa cambió de forma silenciosa pero importante en los últimos cuatro meses. Antes de la explosión de IA generativa, la decisión típica de una empresa mediana se reducía a Postgres o MySQL para datos relacionales, y MongoDB o Dynamo para datos no estructurados. Hoy, cualquier proyecto que toque embeddings o búsqueda semántica obliga a evaluar también una capa de vector search. Pinecone, Weaviate, Qdrant y Milvus pelean ese segmento como productos especializados, mientras que Postgres con pgvector y MongoDB con Atlas Vector Search en preview ofrecen capacidades de vector dentro de la base de datos que ya tenías.
Para una empresa mediana mexicana que está empezando a montar capacidades de RAG o búsqueda semántica, la pregunta práctica es esta: ¿se justifica añadir un servicio nuevo al stack o se aprovecha la infraestructura existente? La respuesta correcta depende del patrón de acceso, no de la moda. Aquí va el marco que usamos para decidir.
Qué es vector search y por qué importa de pronto
Un vector es una representación numérica de un texto, una imagen o cualquier dato. Los modelos de embeddings convierten un párrafo en un arreglo de cientos o miles de números, donde la cercanía geométrica entre dos vectores corresponde a similitud semántica. Buscar vectores similares al vector de una consulta es lo que permite responder "encuéntrame documentos parecidos a esto" sin requerir que las palabras coincidan exactamente.
Hasta hace poco, este tipo de búsqueda estaba limitada a equipos con experiencia en machine learning. Hoy, con APIs de embeddings de OpenAI, Cohere o modelos abiertos, cualquier equipo de desarrollo puede generar embeddings. Lo que faltaba era dónde almacenarlos y cómo buscarlos eficientemente. Eso es lo que ahora ofrece toda esta nueva capa de productos.
Postgres con pgvector
pgvector es una extensión de Postgres que añade un tipo de dato vector y dos índices (IVF Flat y, recientemente, HNSW) para búsqueda eficiente de vecinos cercanos. La instalación es una línea, el uso es SQL estándar.
Cuándo gana. Cuando ya tienes Postgres en producción, cuando el volumen es de cientos de miles a algunos millones de vectores, cuando necesitas combinar búsqueda vectorial con filtros relacionales (búsqueda semántica solo dentro del catálogo de un cliente, por ejemplo), y cuando valoras tener un solo motor de almacenamiento para reducir complejidad operativa.
Cuándo no. Cuando el volumen escala a decenas o cientos de millones de vectores con consultas de baja latencia, donde la presión sobre el CPU del Postgres y la concurrencia con el resto de las cargas se vuelve problema.
Es la opción que recomendamos por defecto para empezar. La fricción de adopción es mínima y permite validar el caso de uso antes de comprometer un servicio adicional.
MongoDB Atlas Vector Search
MongoDB anunció en mayo Atlas Vector Search como capacidad nativa de su servicio gestionado. Está en preview pública. Permite indexar vectores junto con el resto del documento y consultarlos con la misma sintaxis que el resto de la API de MongoDB.
Cuándo gana. Cuando ya tienes MongoDB Atlas como base de datos principal, cuando trabajas con documentos JSON con campos heterogéneos, y cuando los vectores acompañan al documento de forma natural (por ejemplo, embeddings de productos junto con su catálogo).
Cuándo no. Si no usas MongoDB hoy, no es razón suficiente adoptarlo solo por la capacidad vectorial. Hay opciones más enfocadas.
La señal importante de este movimiento de MongoDB es que confirma que las bases de datos generales van a absorber la capacidad vectorial como feature, igual que en su momento absorbieron geoespacial y full-text search. La pregunta de "¿necesito vector DB dedicada?" se va a volver cada vez menos común.
Las vector DBs especializadas
Pinecone, Weaviate, Qdrant y Milvus son los nombres con más tracción. Comparten arquitectura optimizada para vectores como caso primario, no como capacidad añadida.
Pinecone. SaaS gestionado, fácil de empezar, latencias bajas, escala bien a volúmenes grandes. Costo elevado en planes serios, dependencia de un proveedor único.
Weaviate. Open source con opción gestionada, modelo de objetos enriquecido, módulos de generación que integran modelos como GPT directamente. Curva de aprendizaje un poco mayor.
Qdrant. Open source escrito en Rust, performance fuerte, API clara, opción gestionada disponible. Está creciendo rápido en preferencia entre equipos técnicos.
Milvus. Open source maduro, foco en escala muy grande, comunidad activa. Más complejo de operar self-hosted.
Cuándo gana una vector DB especializada. Cuando el volumen es muy alto (decenas de millones de vectores), cuando la latencia bajo concurrencia es crítica, cuando el equipo tiene capacidad para operar un servicio adicional, y cuando las funcionalidades específicas del producto (filtrado complejo, distintos tipos de índices, payload enriquecido) justifican la complejidad.
Cuándo no. Cuando estás al inicio del caso de uso, cuando los volúmenes son moderados, cuando el equipo es pequeño y cada servicio adicional es carga real de operación.
Marco de decisión simple
En ALCA usamos cuatro preguntas para decidir.
1. ¿Cuál es el volumen esperado de vectores en 18 meses? Hasta 10 millones, casi cualquier opción funciona. De 10 a 100 millones, ya hay diferencias notables. Más de 100 millones, vector DB especializada o solución muy pensada en Postgres.
2. ¿Cuál es la latencia objetivo y la concurrencia esperada? Aplicaciones interactivas con cientos de consultas por segundo y latencias por debajo de 100 ms son terreno de vector DB especializada o de Postgres con tuning serio.
3. ¿Qué tan acoplado está el caso a datos relacionales o de documento? Si el filtrado por atributos relacionales o por estructura de documento es central, ganan las opciones integradas (Postgres, MongoDB). Si la búsqueda es casi puramente vectorial, gana la especializada.
4. ¿Qué capacidad tiene el equipo para operar un servicio adicional? Equipos pequeños sin DevOps dedicado se benefician de quedarse en su DB existente. Equipos con plataforma madura pueden absorber un servicio nuevo sin fricción.
Costos comparativos
Una nota sobre costos que muchas evaluaciones omiten. El precio del servicio especializado es solo una parte. Hay que sumar el costo de operación (monitoreo, backups, parcheo, escalado), el costo del enlace de red entre tu aplicación y el servicio si vive fuera, y el costo de la complejidad de tener un sistema más en el inventario.
Para volúmenes moderados, Postgres con pgvector en la misma instancia que la base existente puede costar diez veces menos que cualquier opción especializada. Para volúmenes grandes, la cuenta se invierte.
El error más común que vemos
Equipos eligiendo Pinecone u otra vector DB especializada al inicio del proyecto, sin haber validado el caso de uso, atraídos por el material de marketing. A los seis meses tienen una factura mensual considerable, una capa más en la arquitectura, y un volumen real de vectores que Postgres habría manejado sin pestañear.
La regla pragmática es empezar simple, medir, y migrar cuando los números lo justifiquen. Es más fácil migrar de pgvector a Pinecone con datos reales que justifican el cambio, que migrar de vuelta de Pinecone a pgvector cuando descubres que estás sobreinvirtiendo.
Lo que viene en los próximos meses
Tres apuestas sobre cómo se va a mover este mercado.
Las bases de datos relacionales generales van a seguir sumando capacidades vectoriales cada vez más serias. Las vector DBs especializadas van a tener que diferenciarse por features avanzadas (búsqueda híbrida, filtrado complejo, generación integrada) más allá de la búsqueda básica. Y la conversación de "qué vector DB elegir" va a ser cada vez menos común que la de "cómo armo bien mi pipeline de embeddings", que es donde realmente se gana o se pierde el caso de uso.
¿Quieres una segunda opinión sobre tu elección de DB? Conversemos. En ALCA hacemos un assessment de dos semanas que evalúa tu caso de uso contra dos o tres opciones con datos reales y entrega recomendación con costos y riesgos. Agenda una llamada y revisamos.
