Por qué el RAG de producción está yendo más allá de las bases de datos vectoriales dedicadas
Explora por qué las bases de datos vectoriales independientes están perdiendo terreno en los sistemas RAG de producción y cómo la recuperación híbrida, el filtrado y las capas de datos unificadas están redefiniendo toda la estructura.
Fuentes: The Vector Database Era Is Ending. Here’s What Production RAG Is Moving Toward
Los pipelines de recuperación utilizados en producción rara vez son un mecanismo único. Una configuración moderna puede combinar:
- Recuperación densa para detectar similitud semántica
- Recuperación dispersa para encontrar términos exactos
- BM25 para la puntuación léxica
- Búsqueda híbrida que amplía la tasa de recuperación
- Reclasificación para mejorar la precisión
- Reescritura de consultas para preguntas difíciles o ambiguas
- Autocomprobación y validación de los resultados recuperados
- Recuperación basada en grafos para conocimientos interconectados
- Flujos de trabajo basados en agentes que obtienen información en múltiples pasos
Este artículo analiza por qué el diseño clásico basado en bases de datos vectoriales para la Generación Aumentada por Recuperación está comenzando a resultar insuficiente en muchas implementaciones reales.
Si RAG es un tema nuevo para usted, vale la pena revisar los conceptos básicos antes de adentrarse en cómo los sistemas modernos van más allá de ellos: conceptos como qué es RAG, por qué los LLM generan ilusiones, cómo se construye típicamente un pipeline RAG y la diferencia entre recuperación densa y esparsa son buenos puntos de partida.
Hace ya bastante tiempo que la arquitectura estándar para la Generación Aumentada por Recuperación se ha vuelto casi obligatoria:
LLM → Modelo de Embedding → Base de datos vectorial → Contexto recuperado → LLM
Si estuviera diseñando un producto RAG serio, se esperaba que eligiera un almacén vectorial dedicado: Pinecone, Weaviate, Qdrant, Milvus, Chroma o similares.
Pero el uso en entornos reales está replanteando la pregunta.
Ya no se trata realmente de:
"¿Qué base de datos vectorial debería elegir?"
La pregunta más relevante se ha convertido en:
“¿Realmente necesito una base de datos vectorial dedicada?”
Ese cambio en la forma de plantearlo es muy importante.
Los informes recientes del campo y las comparaciones de pruebas demuestran que cada vez más equipos integran la búsqueda vectorial en la infraestructura que ya utilizan: PostgreSQL con la extensión pgvector, Elasticsearch y diversas plataformas de datos unificadas son opciones comunes.
Esto no significa que las bases de datos vectoriales vayan a desaparecer de la noche a la mañana.
Más bien, indica que considerar una base de datos vectorial independiente como la opción arquitectónica por defecto se está volviendo más difícil de justificar.
Y esta presión se manifiesta justo donde más importa en la ingeniería de IA:
costos de producción, gastos operativos, capacidad de filtrado, consistencia de los datos y calidad general de la recuperación.
1. La base de datos vectorial resolvió un problema real
Es útil revisar primero por qué las bases de datos vectoriales ganaron popularidad en primer lugar.
Las bases de datos convencionales manejan consultas como esta con facilidad:
SELECT *
FROM documents
WHERE category = 'insurance'
AND effective_date > '2025-01-01';
Pero la búsqueda semántica plantea un tipo de pregunta fundamentalmente diferente:
"Encuentra documentos cuyo significado sea similar a esta consulta."
Responder a eso requiere convertir el texto en vectores numéricos:
"How do I file a health insurance claim?"
↓
Embedding Model
↓
[0.021, -0.183, 0.492, ...]
A partir de ahí, la base de datos realiza una búsqueda aproximada de vecinos más cercanos.
A nivel conceptual, esto se ve así:
Query Vector
│
▼
┌─────────┐
│ ANN │
│ Index │
└────┬────┘
│
├── Document A 0.91
├── Document B 0.87
├── Document C 0.84
└── Document D 0.81
Cuando se trabaja con millones o miles de millones de vectores, métodos de indexación especializados como HNSW o IVF pueden acelerar enormemente este proceso en comparación con un escaneo por fuerza bruta.
Por lo tanto, la motivación original tenía todo el sentido:
Diseñar una base de datos creada específicamente para recuperar vectores de manera eficiente.
Para tipos específicos de cargas de trabajo, ese razonamiento sigue siendo válido hoy en día.
Las complicaciones surgieron a partir de lo que vino después.
2. El RAG en producción implica mucho más que la búsqueda de vectores
Los prototipos iniciales de los sistemas RAG suelen seguir un flujo simple:
Question
↓
Embedding
↓
Vector Search
↓
Top 5 chunks
↓
LLM
Los sistemas de producción reales casi nunca se mantienen tan simples.
Lo que normalmente se obtiene en su lugar se parece más a:
┌── Metadata filters
│
├── Tenant isolation
│
Query → Rewrite → Embed ─┼── Keyword search
│
├── Vector search
│
├── ACL filtering
│
├── Recency
│
└── Reranking
│
▼
LLM
En este punto, la base de datos ya no puede limitarse a responder:
“¿Cuáles vectores están más cerca de este?”
Tiene que responder a algo mucho más complejo:
“¿Cuáles documentos están relacionados semánticamente, pertenecen al cliente correcto, siguen siendo válidos, son accesibles para este usuario en particular y cumplen con estos filtros adicionales? ¿Todo al mismo tiempo?”
Ese requisito transforma todo el problema.
3. El costo oculto de utilizar dos bases de datos
Imagínese que su empresa ya depende de PostgreSQL.
Allí se encuentran los datos de su aplicación principal:
PostgreSQL
users
customers
policies
claims
documents
permissions
metadata
Luego se añade una base de datos vectorial al conjunto:
PostgreSQL Vector DB
────────── ──────────
Documents ───────► Embeddings
Users Metadata
Permissions ANN index
Claims
A partir de ese momento, actualizar un documento puede requerir aplicar los cambios en dos sistemas separados.
Un flujo de actualización típico termina pareciéndose a esto:
Document Updated
│
├──────────────► PostgreSQL
│
└──────────────► Embedding Pipeline
│
▼
Vector DB
Esta configuración abre la puerta a problemas de sincronización.
Considere qué debe ocurrir cuando:
- se elimina un documento
- cambian los permisos de un cliente
- una política recibe una nueva versión
- se actualizan los metadatos
- un inquilino se elimina del sistema
- el propio modelo de incrustación se reemplaza
En ese momento, en realidad habrá creado problemas de consistencia de datos distribuidos dentro de su capa de recuperación.
Un artículo de investigación de 2026 que analiza las capas de datos unificadas para RAG señala precisamente este tipo de división —entre almacenamiento relacional y vectorial— como la causa raíz de datos obsoletos, fallos en el aislamiento de usuarios y una composición de consultas excesivamente compleja. Su diseño basado en PostgreSQL más pgvector mostró mejoras significativas en las tareas de recuperación filtrada durante su evaluación, y eliminó los problemas de sincronización que surgen al mantener dos sistemas separados.
Resulta ser un problema de producción mucho más importante que debatir si un método de indexación ANN supera ligeramente a otro en velocidad bruta.
4. La búsqueda vectorial “suficientemente buena” comienza a aparecer en las bases de datos que ya utilizas
Aquí es donde entra en juego PostgreSQL.
Graças a pgvector, una tabla de PostgreSQL puede contener tanto las columnas normales como los embeddings uno al lado del otro:
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT,
metadata JSONB,
embedding VECTOR(1536)
);
Y puedes realizar una consulta de similitud directamente contra esa misma tabla:
SELECT
id,
content,
embedding <=> query_embedding AS distance
FROM documents
WHERE tenant_id = 123
ORDER BY embedding <=> query_embedding
LIMIT 10;
Lo importante aquí no es simplemente que PostgreSQL sea capaz de realizar búsquedas vectoriales.
Sino que esta búsqueda vectorial se ejecuta junto con el resto de los datos de tu aplicación.
Puedes combinar, en una sola consulta y en un único sistema:
SQL filtering
+
Vector similarity
+
Transactions
+
Access control
+
Metadata
Para los equipos que operan sistemas en producción, esa es una propuesta muy atractiva.
Varias comparaciones de sistemas en producción publicadas en 2026 consideran ahora a pgvector como la opción preferida para muchos casos de uso de RAG siempre que PostgreSQL ya forme parte del stack, especialmente cuando la cantidad de vectores es moderada y no masiva.
5. El factor de costos es más significativo de lo que parece
El costo es, sin duda, la razón más fuerte por la que los equipos reconsideran esta arquitectura.
Supongamos que tu stack ya incluye algo como:
PostgreSQL
$300/month
Añadir capacidad vectorial a esa configuración puede ser tan sencillo como:
Existing PostgreSQL
+
pgvector
+
additional CPU/RAM
Compárelo con ejecutar un servicio vectorial gestionado por separado junto a PostgreSQL:
PostgreSQL
+
Pinecone
+
network traffic
+
index management
+
monitoring
+
data synchronization
La diferencia no será significativa para todas las cargas de trabajo.
Pero la sobrecarga arquitectónica se acumula con el tiempo.
Varios estudios de costos para 2026 indican una verdadera diferencia de precios entre los servicios vectoriales gestionados y la búsqueda vectorial basada en PostgreSQL bajo carga moderada. Un benchmark reveló que el costo por consulta de Pinecone es notablemente más alto, mientras que pgvector requería ajustes adicionales para alcanzar un rendimiento similar.
La conclusión no es:
"pgvector siempre es la opción más económica."
Esa afirmación no es válida en todos los casos.
La verdadera conclusión es:
La base de datos vectorial más económica suele ser la que ya está pagando.
6. El costo no es lo que realmente arruina este modelo
Aquí está la realidad menos agradable.
Si el único problema de las bases de datos vectoriales fuera el precio, la solución sería sencilla: reducir costos.
Pero los equipos que operan estos sistemas en producción se enfrentan a un problema diferente y más profundo.
La búsqueda por similitud por sí sola a menudo no es el enfoque adecuado de recuperación.
Tomemos una pregunta similar: un cliente quiere saber qué términos de cancelación aplican a un nivel de suscripción premium en un estado específico, a partir de una fecha concreta a principios del próximo año.
Este tipo de pregunta en realidad contiene varios indicadores de recuperación distintos al mismo tiempo:
Semantic meaning
+
Exact terms
+
Customer segment
+
Geography
+
Effective date
La búsqueda vectorial por sí sola podría captar el significado general de la oración, pero pasar completamente por alto las restricciones precisas que contiene.
Por eso, los sistemas RAG actuales se están diseñando cada vez más para combinar:
BM25
+
Dense Retrieval
+
Metadata Filtering
+
Reranking
en lugar de depender únicamente de la similitud semántica.
Un estudio reciente que analizó la calidad de la recuperación a medida que aumenta el tamaño del corpus —comparando enfoques léxicos, densos, basados en grafos y agentes— descubrió que BM25 mantuvo un rendimiento notablemente bueno, permaneciendo en la frontera de bajo costo de Pareto en todo el rango de tamaños de corpus probados.
Ese resultado por sí solo debería hacer que los ingenieros de RAG se detengan a reflexionar.
Años de esfuerzo se invirtieron en perfeccionar la recuperación semántica.
Pero la búsqueda basada en palabras clave nunca llegó a ser obsoleta.
7. Elasticsearch se ha convertido en un backend legítimo para RAG
Esta tendencia debilita aún más el argumento a favor de las bases de datos vectoriales independientes.
Los motores de búsqueda han manejado durante mucho tiempo:
- índices invertidos
- puntuación BM25
- filtrado
- agregaciones
- búsqueda facetada
- clasificación de relevancia del texto
- búsqueda distribuida
Ahora también manejan búsquedas vectoriales.
Así que, en lugar de arquitecturas basadas en:
PostgreSQL
+
Vector DB
+
Search Engine
los equipos pueden consolidarse hacia algo como:
Search Engine
┌───────────────┐
│ BM25 │
│ Vector Search │
│ Filters │
│ Ranking │
└───────────────┘
Un benchmark comunitario para 2026 que compara pgvector con Elasticsearch, Qdrant, Pinecone y Weaviate fue más allá de la simple latencia de ANN, probando búsquedas filtradas, búsquedas híbridas, comportamiento de escritura/actualización y acceso concurrente en condiciones realistas propias del entorno de producción.
Esa es la categoría de benchmarks que realmente importa en la práctica.
Nadie recibe una notificación de emergencia porque sus valores de similitud coseno sean un 12% más lentos que los de la competencia.
Reciben una notificación porque:
se mostró al cliente el documento incorrecto.
8. La recuperación filtrada es donde realmente tiene lugar la competencia
Esto podría ser el insight arquitectónico más importante en el diseño actual de RAG.
Imagínese un conjunto de datos con 100 millones de vectores.
A un usuario determinado solo se le permite ver resultados que coincidan con:
tenant = ACME
region = US
department = legal
document_status = active
Un proceso ingenuo podría ejecutar algo como:
Vector Search
↓
Top 100
↓
Metadata Filtering
↓
Top 10
Pero para cuando se aplican los filtros posteriormente, es posible que ya se hayan descartado los documentos que realmente eran importantes, porque nunca llegaron a la lista inicial de candidatos obtenida en el paso de búsqueda vectorial.
La recuperación en entornos de producción modernos necesita cada vez más esas restricciones de filtrado para dar forma al propio proceso de recuperación, y no solo para limpiarlo después.
En otras palabras, la consulta que realmente se desea parece más bien:
Semantic Similarity
+
Structured Filtering
+
Authorization
+
Keyword Matching
+
Ranking
En esencia, esto representa un desafío de optimización de consultas a bases de datos.
No se trata simplemente de un desafío de búsqueda vectorial.
9. Las bases de datos vectoriales enfrentan su propia presión por contar con una “capa de datos unificada”
La ingeniería de bases de datos ha dedicado décadas a fusionar diferentes categorías de datos en sistemas únicos. La IA está llevando aún más lejos ese mismo instinto de consolidación.
La arquitectura que está tomando forma se parece más o menos a esto:
Unified Data Layer
│
┌───────────────────┼───────────────────┐
│ │ │
Relational Vector Search
│ │ │
SQL / joins ANN/HNSW BM25
│ │ │
└───────────────────┼───────────────────┘
│
Graph
│
Relationships
Y potencialmente se extiende hacia algo como esto:
RAG Query
│
▼
Query Planning Layer
│
┌────────────┼────────────┐
▼ ▼ ▼
Vector BM25 SQL
Search Search Filters
│ │ │
└────────────┼────────────┘
▼
Reranker
│
▼
LLM
Esto refleja con mucha mayor precisión cómo funciona en realidad la recuperación de datos dentro de los sistemas empresariales reales que lo hace un almacén de vectores independiente.
La investigación actual en sistemas de bases de datos está analizando activamente motores que ejecutan búsquedas por similitud vectorial, recorrido de grafos y filtrado relacional como una operación coordinada en lugar de como pasos separados y secuenciales de recuperación. Esa dirección representa un cambio significativo en la forma en que se diseña la infraestructura de recuperación.
10. ¿Están terminados Pinecone, Qdrant y Milvus?
Para nada.
Esta es la parte del argumento que requiere matices.
Las bases de datos vectoriales diseñadas específicamente siguen siendo la opción adecuada en varias situaciones.
Cuando tu colección de vectores es masiva. Si operas con:
500M+
1B+
10B+ vectors
y la recuperación de vectores es un componente fundamental de tu infraestructura, los sistemas dedicados justifican su complejidad.
Cuando necesitas un alto rendimiento en las consultas. Si esencialmente tu producto consiste en atender consultas vectoriales rápidamente, a volúmenes que alcanzan:
Millions of queries
per second
no es práctico enrutar todo a través de una base de datos transaccional de uso general.
Cuando necesitas un ajuste avanzado de ANN. Las plataformas especializadas te brindan un control preciso sobre HNSW, IVF, cuantización, sharding, replicación, búsqueda distribuida de vecinos más cercanos aproximados y aceleración por GPU.
Cuando se necesita aislamiento de la infraestructura. Mantener las cargas de trabajo de recuperación separadas de los sistemas transaccionales principales puede ser una elección deliberada y sensata, para que las funciones de IA no se conviertan en fuente de conflictos en la base de datos.
11. Qué es lo que realmente está desapareciendo
No se trata de la búsqueda vectorial en sí. Tampoco son los embeddings, el indexado ANN ni RAG como patrón general.
Lo que está perdiendo terreno es una suposición específica:
"Cada sistema RAG en producción requiere su propia base de datos vectorial dedicada."
Esa premisa resulta cada vez más difícil de justificar por defecto. Para una gran parte de las aplicaciones, la configuración puede ser simplemente así:
PostgreSQL
│
├── Relational Data
├── Metadata
├── Permissions
├── Full-text Search
└── pgvector
│
▼
RAG
en lugar de esto:
PostgreSQL
│
├──── Vector DB
│
├──── Search Engine
│
└──── Cache
Cada sistema adicional que se introduce añade otra interconexión operativa, y cada una de ellas representa un posible punto de fallo.
12. Una forma más útil de decidir
En lugar de preguntarse cuál es la base de datos vectorial más rápida, haga preguntas relacionadas con su escala real.
Menos de 1 millón de vectores: manténgalo simple. Si PostgreSQL ya forma parte de su stack, pgvector merece ser su primera opción de evaluación. No hay necesidad de incorporar otra base de datos solo porque así lo indica un tutorial.
Entre 1 millón y 50 millones de vectores: aquí es donde realmente importan las pruebas de rendimiento. Compare opciones como:
pgvector
vs
Qdrant
vs
Weaviate
vs
Pinecone
vs
Elasticsearch
Pero evalúe la latencia p95/p99, la calidad de la recuperación filtrada, el rendimiento de la búsqueda híbrida, el ancho de banda de inserción, el comportamiento al actualizar y eliminar datos, el consumo de memoria, el costo operativo y la recuperación ante fallos, y no solo la velocidad bruta del algoritmo ANN top-k.
Entre 50 millones y más de 500 millones: los sistemas dedicados comienzan a ser una opción muy viable, incluyendo:
Qdrant
Milvus
Pinecone
Weaviate
Elasticsearch
specialized vector infrastructure
Su elección ahora depende de los objetivos de QPS, la dimensionalidad del vector, el tipo de índice, las necesidades de replicación, los presupuestos de latencia, las limitaciones de memoria y la complejidad del filtrado.
Más de 500 millones de vectores: deje de confiar en las clasificaciones genéricas de “mejor base de datos de vectores” y cree un punto de referencia específico para su carga de trabajo. A esta escala, pequeños errores arquitectónicos pueden traducirse en costos de infraestructura que se miden en cifras de seis dígitos.
13. Así es la pila RAG actualmente
La típica pila RAG de 2023 se veía así:
LLM
│
Embedding Model
│
Vector Database
│
Retriever
│
LLM
La pila en producción que está surgiendo para 2026 es notablemente diferente:
User Query
│
▼
Query Planner
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
BM25 Vector SQL
Search Search Filters
│ │ │
└─────────────┼─────────────┘
▼
Reranker
│
▼
Context Selection
│
▼
LLM
Lo que falta en esa imagen es revelador: la suposición de que la búsqueda vectorial se encuentra en el centro del proceso de recuperación. Ya no es así. La búsqueda vectorial se ha convertido en solo uno de los métodos de recuperación entre varios, y no en el eje alrededor del cual gira todo el sistema.
14. Una conclusión más amplia para los ingenieros de IA
Este patrón dice algo sobre la infraestructura de IA en su conjunto.
Al principio, la industria solía crear un sistema dedicado para cada nueva funcionalidad:
LLM → New database
Embeddings → New database
Vector search → New database
Agents → New orchestration layer
RAG → New retrieval layer
Pero con el tiempo, los equipos de producción comienzan a hacerse una pregunta más simple:
"¿Podríamos fusionar algunas de estas funciones?"
Cada servicio adicional que se implementa añade:
More cost
More monitoring
More networking
More credentials
More failure modes
More backups
More synchronization
More operational knowledge
Las herramientas especializadas suelen salir ganando en las pruebas de rendimiento.
Los sistemas consolidados suelen tener más éxito en la producción real.
Esa es precisamente la razón por la cual PostgreSQL se ha convertido en una opción tan atractiva dentro del stack de IA en la actualidad.
No tiene por qué ser el motor vectorial más rápido disponible.
Solo necesita ser:
suficientemente rápido, lo suficientemente económico, lo suficientemente fiable y lo suficientemente bien integrado.
Para una gran parte de las aplicaciones reales, esa combinación es realmente difícil de superar.
15. Las bases de datos vectoriales no están desapareciendo: se están redefiniendo
El resultado real es más complejo que una simple narrativa de que “las bases de datos vectoriales ya no sirven”.
Es de esperar que el ecosistema se organice en tres niveles principales.
Nivel 1: Búsqueda vectorial integrada en la base de datos
PostgreSQL + pgvector
Elasticsearch
OpenSearch
other unified databases
Este nivel es adecuado para equipos que quieren minimizar la cantidad de sistemas a gestionar.
Nivel 2: Bases de datos vectoriales diseñadas específicamente para ello
Pinecone
Qdrant
Weaviate
Milvus
Este nivel tiene sentido cuando la recuperación de vectores por sí sola justifica el uso de una infraestructura dedicada e independiente.
Nivel 3: motores de recuperación especializados
Para cargas de trabajo excepcionalmente grandes o exigentes:
GPU indexes
quantized indexes
distributed ANN
custom retrieval engines
hybrid vector/graph systems
La categoría no está desapareciendo.
Se está dividiendo en capas.
Pensamiento final
El verdadero cambio no es solo que PostgreSQL ahora puede almacenar vectores.
Sino que los ingenieros están comenzando a ajustar toda la cadena de recuperación en lugar de solo una parte de ella.
A un sistema RAG en producción no le importa si los informes de pruebas ANN indican:
8 ms
vs
12 ms
si la ruta real de la solicitud está realmente consumiendo:
40 ms → query processing
30 ms → network
80 ms → reranking
500 ms → LLM
La base de datos de vectores nunca fue realmente el objetivo final.
La calidad de la recuperación sí lo fue.
Una vez que se consideran todos los aspectos: costo, latencia, filtrado, seguridad, consistencia, mantenimiento y relevancia, resulta mucho más difícil justificar la creación de otra base de datos independiente.
Por lo tanto, la conclusión honesta es:
Las bases de datos vectoriales no están muriendo.
Está ocurriendo algo mucho más interesante.
La búsqueda vectorial se está convirtiendo en una característica de las bases de datos.
Y cuando una tecnología pasa de ser su propia categoría de producto a convertirse en una característica, todo lo relacionado con la arquitectura circundante cambia de forma permanente.