Elegir base de datos vectorial por la restricción que de verdad va a apretar

La secuencia habitual: alguien lee un benchmark donde un motor vectorial dedicado hace 20.000 consultas por segundo con un 99 por ciento de recall, lo elige, y seis meses después el asistente sirve cuarenta consultas por minuto, el problema de recall resulta ser de fragmentación y el equipo opera un sistema distribuido con estado que nadie de guardia entiende.

El caudal de consultas casi nunca es la restricción que aprieta. Las que aprietan son el filtrado por metadatos a gran escala, el aislamiento entre inquilinos, la frecuencia de actualización y el coste operativo de un componente más en un sistema que ya tiene bastantes. Elige por eso.

pgvector es el valor por defecto, y aguanta más de lo que crees

Si tus datos ya viven en PostgreSQL, empieza ahí. pgvector te da índices HNSW e IVFFlat, distancia coseno y producto interno, y lo que los motores dedicados ponen difícil: tus vectores están en la misma transacción que tus filas de negocio. Insertas un documento y sus fragmentos de forma atómica, cruzas similitud contra la tabla de permisos en una sola consulta y lo respaldas con la copia que ya tienes.

El techo existe, pero está más alto de lo que dice el folclore. Con memoria suficiente para alojar el índice HNSW, unos pocos millones de vectores con p95 por debajo de 100 ms es rutina. El modo de fallo no es el número de vectores, es la memoria: si el índice no cabe en RAM te caes por un acantilado, y un índice HNSW sobre vectores de 1536 dimensiones ronda los 6 a 8 KB por fila contando las aristas del grafo. Haz esa multiplicación antes de comprometerte con nada: es el cálculo que predice el dolor.

Una nota operativa: la construcción del índice compite con tu tráfico OLTP por la misma caché de buffers, así que si esa base de datos sirve además tu ruta de compra, pon los vectores en otro sitio.

El filtrado por metadatos es donde se rompen las arquitecturas

Todo sistema RAG serio filtra: por inquilino, por grupo de permisos, por tipo de documento, por fecha. Como se explica en las cuatro decisiones que importan más que el modelo, ese filtro tiene que aplicarse antes de ordenar y no después, o acabas con conjuntos vacíos y filtrando la existencia de documentos.

Aquí es donde los almacenes se diferencian de verdad. Postgres puede combinar un WHERE con un índice vectorial, pero el planificador puede filtrar primero y recorrer por fuerza bruta a los supervivientes: rápido con un filtro estrecho, pésimo con uno amplio. Qdrant y Weaviate implementan recorrido HNSW filtrado, que mantiene el recall mientras restringe la búsqueda. Si tu consulta típica filtra a una porción pequeña e impredecible de un corpus grande, esa diferencia justifica una migración. Si tu filtro es un inquilino de doscientos con 50.000 fragmentos cada uno, particiona la tabla de Postgres por inquilino y el problema desaparece.

La multitenencia y la frecuencia de cambio deciden más que el volumen

Dos preguntas predicen la necesidad de un motor dedicado mejor que el número de filas.

¿Cuántos inquilinos y cuánto aislamiento necesitan? Unos pocos: esquemas o particiones separadas en Postgres. Miles de inquilinos pequeños: quieres un almacén con colecciones de primera clase o índices conscientes del inquilino, porque miles de particiones de Postgres es un problema de planificador.

¿Con qué frecuencia cambia el corpus? Una base de conocimiento que se reindexa cada noche es fácil en cualquier sitio. Un sistema que ingiere miles de fragmentos por hora con borrados es donde IVFFlat se degrada, HNSW solo trata los borrados como lápidas, y los motores diseñados alrededor de la compactación por segmentos se ganan el sueldo.

La búsqueda híbrida no es opcional y cambia la lista corta

La búsqueda puramente vectorial falla de forma predecible con identificadores exactos, códigos de producto, cadenas de error y nombres propios raros: donde el usuario escribe literalmente el término que quiere. BM25 acierta ahí y falla con las paráfrasis. Necesitas las dos, con las listas fusionadas, normalmente por fusión de rangos recíprocos.

Postgres lo hace de forma nativa: un índice GIN sobre tsvector junto a la columna vectorial, dos CTE y la fusión en SQL. Cuarenta líneas, y uno de los mayores saltos de calidad disponibles. Algunos motores dedicados traen la búsqueda híbrida incorporada; otros esperan que levantes un OpenSearch al lado, o sea, dos sistemas igualmente. Tenlo en cuenta.

Los servicios gestionados y lo que te cuestan en opcionalidad

Cada nube tiene su respuesta: colecciones vectoriales de Amazon OpenSearch Serverless y Aurora con pgvector, Vertex AI Vector Search, Azure AI Search, más Pinecone como principal independiente. Quitan trabajo operativo real.

El bloqueo no es uniforme, y esa es la parte que hay que pesar. Aurora con pgvector o Azure Database for PostgreSQL te dejan sobre la API de Postgres: irse es un pg_dump. Vertex AI Vector Search y Azure AI Search tienen APIs propietarias y su propia semántica de filtrado e híbrido: irse es reescribir la capa de recuperación más una reindexación completa. Puede ser un trato razonable, pero hazlo con conocimiento y mantén la tubería de fragmentación y embeddings independiente del almacén, para que la reindexación sea un script y no un proyecto.

Cosas que se olvidan

• El índice no es tu fuente de verdad. Guarda los fragmentos, su texto y sus metadatos en almacenamiento duradero que controles. Vas a reconstruir el índice más de una vez.
• Cambiar de modelo de embeddings obliga a reindexar entero. Cambian las dimensiones y la geometría. Es la decisión más cara de equivocar, y por eso pertenece a fragmentación y embeddings y no a la elección de base de datos.
• Copias de seguridad y simulacros de restauración. Varios motores dedicados tratan los snapshots como función manual o de pago. Prueba una restauración antes de necesitarla.
• El coste tiene forma de memoria, no de consulta. La búsqueda vectorial es un juego de RAM. Las ofertas serverless suelen facturar por tamaño almacenado más un mínimo de cómputo, y ese mínimo es lo que sorprende en la revisión financiera.
• La latencia incluye la llamada de embedding. Vectorizar la consulta es una ida y vuelta a un modelo, a menudo de 30 a 80 ms. Tu base de datos rápida es una parte de un conjunto más lento.

La respuesta correcta para la mayoría de los equipos con los que trabajamos en un proyecto de IA aplicada es pgvector hasta tener un motivo medido para irte, con ese motivo escrito de antemano.

Qué hacer esta semana

Coge tu corpus actual o previsto, multiplica el número de fragmentos por 7 KB y compáralo con la RAM de la instancia de Postgres que usarías. Después escribe una frase nombrando la restricción que esperas encontrarte primero: volumen, selectividad del filtro, número de inquilinos o ritmo de actualización. Esa frase, y no un benchmark, es tu criterio.