Bases de Datos Vectoriales en 2026: Cuál Elegir para RAG

1. Bases de Datos Vectoriales: Visión General

Una base de datos vectorial almacena vectores de embedding de alta dimensión y responde rápido a una pregunta: "¿cuáles de los vectores almacenados están más cerca de este vector de consulta?" Esa búsqueda del vecino más cercano es el motor de recuperación detrás de RAG, la búsqueda semántica, las recomendaciones, la deduplicación y la búsqueda de imágenes o audio. La base de datos no es lo que hace buenos tus resultados -- tu modelo de embedding fija el techo de calidad -- pero es lo que hace la recuperación rápida, filtrable, durable y económica a escala. Para RAG en concreto, es el componente que convierte un montón de embeddings en contexto fundamentado en menos de 100ms.

Una base de datos vectorial hace tres tareas: almacenar vectores junto con su metadata (payload) de forma durable, indexarlos con una estructura de vecino más cercano aproximado (ANN) para que la búsqueda no escanee cada fila, y buscar con una métrica de distancia mientras aplica filtros de metadata. En 2026 la verdadera decisión no es "qué base de datos tiene búsqueda vectorial" -- casi todas la tienen -- sino qué tradeoff entre recall, latencia, poder de filtrado, carga operativa y costo encaja con tu carga de RAG. Esta guía compara las seis que importan: pgvector, Qdrant, Pinecone, Weaviate, Milvus y Chroma.

2. Algoritmos de Indexación (HNSW, IVFFlat, DiskANN)

El índice es el mayor determinante de la velocidad, el recall, el uso de memoria y el tiempo de construcción de una base de datos vectorial. Casi todo motor usa HNSW por defecto hoy, pero las variantes de IVF y DiskANN importan para corpus grandes o con memoria limitada. Entender qué hace cada uno -- y qué perillas mueven el recall vs la latencia -- te permite ajustar cualquier base de datos en vez de confiar en los defaults. Las familias de abajo son las que realmente vas a encontrar en pgvector, Qdrant, Pinecone, Weaviate y Milvus.

3. Métricas de Distancia y Similaridad

La métrica de distancia define qué significa "más cercano", y debe coincidir con cómo fue entrenado tu modelo de embedding. Elige la equivocada y el recall colapsa en silencio -- el índice funciona, pero retorna los vecinos incorrectos. Cada métrica también mapea a una clase de operador de índice específica (pgvector) o a un campo de configuración (Qdrant, Milvus, Weaviate, Pinecone). La regla práctica: lee la ficha de tu modelo de embedding y usa la métrica que recomienda, luego normaliza si eso te permite usar el operador más rápido.

4. Búsqueda Filtrada e Híbrida

La búsqueda vectorial pura es rara en RAG de producción. Casi siempre restringes los resultados por metadata (tenant, permisos, fecha, tipo de documento) y a menudo mezclas la similaridad semántica con la coincidencia por keywords. Cómo maneja una base de datos la búsqueda filtrada e híbrida -- correctamente y sin arruinar el recall -- es uno de los mayores diferenciadores prácticos entre motores. Aquí es donde el pre-filtrado de Qdrant y la búsqueda híbrida nativa de Weaviate se ganan su reputación, y donde el post-filtrado ingenuo retorna en silencio muy pocos resultados.

5. Las Bases de Datos Comparadas

Estas seis cubren esencialmente todo escenario de RAG en 2026, desde un proyecto paralelo en una caja Postgres existente hasta una plataforma de búsqueda de mil millones de vectores. Todas hacen HNSW, filtrado por metadata y consultas sub-100ms a escala de millones -- así que la decisión se reduce al poder de filtrado, la búsqueda híbrida, el techo de escala y cuánta superficie operativa quieres poseer. Lee cada una con tu propia carga en mente; la tabla de decisión en la sección 8 mapea casos de uso a elecciones.

6. Cuantización y Memoria

La memoria es el costo dominante de la búsqueda vectorial. Un millón de vectores float32 de 1536 dimensiones son ~6 GB solo para los arreglos crudos, antes de que el grafo HNSW lo duplique -- y HNSW lo quiere todo en RAM. La cuantización comprime los vectores para caber más por nodo y recortar costo, sacrificando un poco de exactitud que una pasada de rescoring usualmente recupera. Entender las cuentas de memoria y la escalera de cuantización es cómo mantienes un índice RAG grande económico sin arruinar el recall.

7. Escala, Latencia y Rendimiento

"Rápido" no significa nada sin decir a qué recall, a qué tamaño de dataset y bajo qué filtros. Los benchmarks de proveedores escogen a dedo datasets limpios y sin filtrar al recall que los favorece. Para elegir bien, aprende a leer la curva recall-vs-QPS, dimensiona la memoria con honestidad y ten en cuenta el tiempo de construcción y los cold starts. Esta sección trata de medir el rendimiento sobre tu carga en vez de confiar en un número de marketing.

8. Self-Host vs Gestionado y Costo

El modelo de despliegue moldea el costo, el control y cuánto tiempo de tu equipo consume la base de datos. El espectro va desde serverless completamente gestionado (problema de otro, precio medido) pasando por clústeres gestionados y motores self-hosted hasta una librería embebida dentro de tu app. No hay una respuesta universalmente correcta -- solo el ajuste correcto para tu escala, necesidades de cumplimiento, infraestructura existente y apetito por la operación. Modela el costo total, no solo el precio de lista.

9. Guía de Decisión por Caso de Uso

No hay una única mejor base de datos vectorial -- solo el mejor ajuste para tus restricciones. Parte de lo que ya corres y de cuántos vectores tienes, luego deja que las necesidades de filtrado, la escala y el apetito operativo desempaten. El default que sorprende a la gente: si ya corres PostgreSQL y tienes menos de unos pocos millones de vectores, pgvector es muy a menudo la respuesta correcta, y elimina toda la decisión de "qué base de datos vectorial". Los escenarios de abajo mapean situaciones comunes de RAG a una elección.

# Quick RAM sizing to decide "one node vs quantize/shard"
def ram_gb(n_vectors, dims, bytes_per_component=4, hnsw_m=16):
    vec_bytes   = n_vectors * dims * bytes_per_component      # raw vectors
    graph_bytes = n_vectors * hnsw_m * 12                     # ~HNSW links
    total = (vec_bytes + graph_bytes) * 1.3                   # +30% headroom
    return round(total / 1e9, 2)

# 5M vectors, 1536 dims, HNSW m=16
print("float32:", ram_gb(5_000_000, 1536), "GB")             # ~46 GB  -> big node
print("int8   :", ram_gb(5_000_000, 1536, bytes_per_component=1), "GB")  # ~12 GB
print("MRL-768 int8:", ram_gb(5_000_000, 768, bytes_per_component=1), "GB")  # ~6 GB

# Rule of thumb:
#   fits comfortably in one node's RAM     -> pgvector / single Qdrant / Chroma
#   too big for RAM but budget matters     -> quantize (int8/binary) or DiskANN
#   still too big or needs > 1 node of QPS -> Milvus / sharded Qdrant / Pinecone

10. Operación en Producción

Llevar una base de datos vectorial a producción es más que una consulta que funciona. Necesitas actualizaciones incrementales, backups, aislamiento de tenants, monitoreo y una historia de costo que sobreviva al crecimiento. El algoritmo de recuperación es la parte fácil; la superficie operativa -- mantener el índice fresco, durable, aislado y observable -- es lo que separa un demo de un sistema que puedes operar a las 3am.

11. Ejemplos de Código de Cliente

La misma tarea de RAG -- crear una colección, hacer upsert de embeddings con metadata, ejecutar una búsqueda de similaridad filtrada -- a través de los cuatro motores que es más probable que elijas. Cada uno usa el cliente actual de 2026 y muestra una configuración HNSW/coseno más filtrado por metadata. Los embeddings vienen de cualquier modelo (se muestra OpenAI text-embedding-3); cambia por el tuyo. Estas son las 20 líneas que cargan el peso; envuélvelas en tu código de ingestión y generación.

pgvector (Python + SQL, HNSW)

import psycopg2, json, openai

client = openai.OpenAI()
conn = psycopg2.connect("postgresql://user:pass@localhost:5432/ragdb")

def embed(text: str) -> list[float]:
    r = client.embeddings.create(model="text-embedding-3-small",
                                 input=text, dimensions=1536)
    return r.data[0].embedding

# Setup: extension, table, and an HNSW cosine index
with conn.cursor() as cur:
    cur.execute("CREATE EXTENSION IF NOT EXISTS vector")
    cur.execute("""
        CREATE TABLE IF NOT EXISTS documents (
            id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
            content   TEXT NOT NULL,
            tenant_id TEXT,
            year      INT,
            embedding vector(1536)
        )""")
    cur.execute("""
        CREATE INDEX IF NOT EXISTS docs_emb_idx ON documents
        USING hnsw (embedding vector_cosine_ops)
        WITH (m = 16, ef_construction = 200)""")
    # index the columns you filter on
    cur.execute("CREATE INDEX IF NOT EXISTS docs_tenant_idx ON documents (tenant_id, year)")
    conn.commit()

def upsert(content, tenant_id, year):
    with conn.cursor() as cur:
        cur.execute(
            "INSERT INTO documents (content, tenant_id, year, embedding) "
            "VALUES (%s, %s, %s, %s::vector)",
            (content, tenant_id, year, str(embed(content))))
    conn.commit()

def search(query, tenant_id, k=5):
    qv = str(embed(query))
    with conn.cursor() as cur:
        cur.execute("SET LOCAL hnsw.ef_search = 100")          # recall/latency knob
        cur.execute("""
            SELECT content, 1 - (embedding <=> %s::vector) AS score
            FROM documents
            WHERE tenant_id = %s AND year >= 2025               -- pre-filter
            ORDER BY embedding <=> %s::vector
            LIMIT %s""", (qv, tenant_id, qv, k))
        return cur.fetchall()

print(search("how do I rotate API keys?", tenant_id="acme"))

Qdrant (búsqueda filtrada, cliente Python)

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition,
    MatchValue, Range, PayloadSchemaType,
)
import openai

oai = openai.OpenAI()
client = QdrantClient(url="http://localhost:6333")   # or QdrantClient(url=..., api_key=...)

def embed(text: str) -> list[float]:
    return oai.embeddings.create(model="text-embedding-3-small",
                                 input=text, dimensions=1536).data[0].embedding

# 1. Create a collection (HNSW + cosine are the defaults)
#    recreate_collection is deprecated -- check existence, then create
if not client.collection_exists("docs"):
    client.create_collection(
        collection_name="docs",
        vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
    )
# index the payload fields you filter on -> fast pre-filtering
client.create_payload_index("docs", "tenant_id", PayloadSchemaType.KEYWORD)
client.create_payload_index("docs", "year", PayloadSchemaType.INTEGER)

# 2. Upsert vectors with metadata payloads
def upsert(idx, content, tenant_id, year):
    client.upsert("docs", points=[PointStruct(
        id=idx, vector=embed(content),
        payload={"content": content, "tenant_id": tenant_id, "year": year})])

# 3. Filtered similarity search (filter applied BEFORE the vector walk)
def search(query, tenant_id, k=5):
    hits = client.query_points(
        collection_name="docs",
        query=embed(query),
        query_filter=Filter(must=[
            FieldCondition(key="tenant_id", match=MatchValue(value=tenant_id)),
            FieldCondition(key="year", range=Range(gte=2025)),
        ]),
        limit=k, with_payload=True,
        search_params={"hnsw_ef": 100},          # recall/latency knob
    ).points
    return [(h.payload["content"], h.score) for h in hits]

print(search("how do I rotate API keys?", tenant_id="acme"))

Pinecone (serverless)

from pinecone import Pinecone, ServerlessSpec
import openai

oai = openai.OpenAI()
pc = Pinecone(api_key="your-api-key")

def embed(text: str) -> list[float]:
    return oai.embeddings.create(model="text-embedding-3-small",
                                 input=text, dimensions=1536).data[0].embedding

# 1. Create a serverless index (nothing to size or scale)
if not pc.has_index("docs"):
    pc.create_index(
        name="docs", dimension=1536, metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="us-east-1"))
index = pc.Index("docs")

# 2. Upsert vectors with metadata; namespaces isolate tenants
def upsert(idx, content, tenant_id, year):
    index.upsert(namespace=tenant_id, vectors=[{
        "id": idx, "values": embed(content),
        "metadata": {"content": content, "year": year}}])

# 3. Filtered query within a tenant namespace
def search(query, tenant_id, k=5):
    res = index.query(
        namespace=tenant_id,
        vector=embed(query),
        top_k=k, include_metadata=True,
        filter={"year": {"$gte": 2025}})
    return [(m["metadata"]["content"], m["score"]) for m in res["matches"]]

print(search("how do I rotate API keys?", tenant_id="acme"))

Weaviate (búsqueda híbrida nativa)

import weaviate
from weaviate.classes.config import Configure, Property, DataType
from weaviate.classes.query import Filter
import openai

oai = openai.OpenAI()
client = weaviate.connect_to_local()          # or connect_to_weaviate_cloud(...)

def embed(text: str) -> list[float]:
    return oai.embeddings.create(model="text-embedding-3-small",
                                 input=text, dimensions=1536).data[0].embedding

# 1. Create a collection; we supply our own vectors
if not client.collections.exists("Docs"):
    client.collections.create(
        "Docs",
        vector_config=Configure.Vectors.self_provided(),
        properties=[
            Property(name="content", data_type=DataType.TEXT),
            Property(name="tenant_id", data_type=DataType.TEXT),
            Property(name="year", data_type=DataType.INT),
        ])
docs = client.collections.get("Docs")

# 2. Insert objects with their vectors
def upsert(content, tenant_id, year):
    docs.data.insert(
        properties={"content": content, "tenant_id": tenant_id, "year": year},
        vector=embed(content))

# 3. Hybrid search: BM25 keywords + vector, fused by RRF, with a filter
def search(query, tenant_id, k=5):
    res = docs.query.hybrid(
        query=query,                 # keyword side (BM25)
        vector=embed(query),         # semantic side
        alpha=0.5,                   # 0 = keyword only, 1 = vector only
        filters=Filter.by_property("tenant_id").equal(tenant_id)
                & Filter.by_property("year").greater_or_equal(2025),
        limit=k)
    return [(o.properties["content"], o.metadata.score) for o in res.objects]

print(search("how do I rotate API keys?", tenant_id="acme"))
client.close()