Comparación de ocho bases de datos vectoriales gratuitas para agentes de IA: límites, adecuación y compromisos.
Ocho bases de datos vectoriales con planes gratuitos comparadas en cuanto a memoria para agentes: límites estrictos, adecuación para implementación, concurrencia y cuál de ellas es la más adecuada para los agentes de IA en su entorno.
Ocho bases de datos vectoriales surgen una y otra vez cuando la gente crea agentes con un presupuesto limitado: VectorAI DB Community Edition, Qdrant, Weaviate, Milvus, ChromaDB, LanceDB, pgvector y Pinecone. Cada una es gratuita para comenzar. Eso es diferente a ser gratuita a gran escala, y también distinto a poder desplegarse dondequiera que tenga que ejecutarse el agente.
Los agentes dependen más de un almacén vectorial que cualquier pipeline RAG individual. Su memoria se escribe y se lee una y otra vez a lo largo de muchas sesiones. Por eso es necesario saber si esa memoria perdura después de un reinicio, cómo se comportan los tiempos de respuesta cuando las llamadas se superponen, y si el motor puede ubicarse junto al agente, incluso en un dispositivo con una conexión inestable o ausente.
La versión gratuita no puede cubrir todo eso. Para comprobar cómo se comporta la latencia bajo una carga concurrente real, generalmente se necesita un plan de pago lo suficientemente amplio como para generar dicha carga. Aun así, las versiones gratuitas sí revelan dónde establece cada proveedor sus límites, y algunos de esos límites descartan una opción incluso antes de escribir cualquier código. Un servicio elimina un clúster inactivo después de 14 días. Otro no cuenta con versión autohospedada, lo que lo descarta si los datos no pueden salir de su infraestructura. Cada entrada a continuación indica claramente sus límites, para que pueda adaptar una base de datos a su implementación y saber qué tendría que sacrificar. Los límites, topes y precios cambian con frecuencia, así que confirme las cifras actuales en la página de precios del propio proveedor antes de tomar una decisión.
Criterios
Se compararon ocho bases de datos según cinco aspectos relevantes específicamente para los agentes.
- Tipo de plan gratuito. Totalmente autohospedable sin límite en vectores, un plan gratuito gestionado con límite de almacenamiento o vectores, o una biblioteca en lugar de una base de datos.
- Patrón de memoria adecuado. El diseño de memoria del agente que la base de datos facilita.
- Latencia bajo carga. Cómo se comporta cuando varias llamadas de agentes llegan al mismo tiempo.
- Viabilidad en entornos locales. Si puede ejecutarse completamente en sus propias máquinas sin dependencia de la nube.
- Qué falla al superar el plan gratuito. El punto en el que algo deja de funcionar o comienza a costar dinero.
La mayoría de las comparaciones publicadas están dirigidas a cargas de trabajo de RAG o de recomendaciones, en las cuales la base de datos responde a solicitudes sin estado y se reconstruye a partir de un conjunto fijo de documentos. Los agentes difieren porque acumulan memoria a lo largo de las sesiones. El almacén debe persistir el estado y no solo responder a consultas, lo que cambia qué compromisos son aceptables.
Los ocho, uno por uno
1. VectorAI DB Community Edition
VectorAI DB es una base de datos vectorial que se ejecuta por uno mismo, diseñada para funcionar de manera idéntica en una laptop de desarrollador y en un entorno de producción desconectado.
Nivel gratuito. La Community Edition se instala de forma autogestionada y tiene un límite de 5,000 vectores, que es el límite más bajo en esta versión. Se dice que una prueba de 30 días separada eleva ese límite a un millón. Se entrega como un único contenedor Docker sin dependencias externas como Kubernetes, etcd o almacenamiento de objetos. Su creador ha publicado resultados de pruebas que indican alrededor de 745 consultas por segundo con 10 millones de vectores de 768 dimensiones en una máquina de 64 GB, con una ventaja de 22 veces sobre Milvus y Qdrant Local en el mismo hardware. Considere eso como una afirmación del proveedor: describe el motor de pago con 10 millones de vectores y no la versión gratuita con 5,000 vectores.
Es adecuado para agentes cuando el agente debe ejecutarse donde se encuentran los datos y no donde tiene un centro de datos el proveedor en la nube: ubicaciones aisladas, reglas estrictas de residencia de datos, hardware periférico como NVIDIA Jetson y Raspberry Pi, o en cualquier lugar donde el propio tránsito de datos a la nube sea un problema. El proveedor describe configuraciones listas para cumplir con las normativas para las aplicaciones que se desarrollan sobre ellas, lo cual no es lo mismo que una certificación que viene con la edición gratuita.
Patrón de memoria. Memoria para agentes periféricos y sin conexión, así como memoria duradera en general. Los datos se guardan en el disco y vuelven a cargarse después de un reinicio, y el hecho de contar con solo un contenedor para ejecutarse es lo que hace práctico su uso en entornos sin conexión o aislados cuando Kubernetes no está disponible.
Desventaja. Debes alojarlo tú mismo, punto. No existe ningún plan en la nube gestionado de forma gratuita, a diferencia de Pinecone o Qdrant Cloud, por lo que un equipo que no quiere que nadie ejecute servidores debería elegir otra opción.
# VectorAI DB -- basic similarity search.
from actian_vectorai import VectorAIClient, VectorParams, Distance
with VectorAIClient("localhost:6574") as client:
client.collections.create(
"agent_memory",
vectors_config=VectorParams(size=768, distance=Distance.Cosine),
)
client.points.upsert(
"agent_memory",
points=[{"id": 1, "vector": [0.1] * 768, "payload": {"text": "example memory"}}],
)
results = client.points.search(
"agent_memory",
query_vector=[0.1] * 768,
limit=5,
)
2. Qdrant
Qdrant es una base de datos vectorial de código abierto escrita en Rust. Puedes alojarla tú mismo sin límites de vectores o ejecutarla en Qdrant Cloud.
Nivel gratuito. Ejútala en tu propio hardware: Qdrant no cuesta nada y no tiene límite máximo (licencia Apache 2.0). En Qdrant Cloud, el plan gratuito ofrece un nodo único permanente con medio vCPU, 1 GB de memoria y 4 GB de almacenamiento, lo cual es suficiente para aproximadamente un millón de vectores de 768 dimensiones.
Adecuado para agentes cuando necesitas búsquedas rápidas y filtradas en entornos de producción, además de contar con bibliotecas para Python, TypeScript, Rust, Go, Java y .NET.
Patrón de memoria. Memoria persistente del agente. El filtrado de la carga útil combinado con la búsqueda vectorial permite al agente almacenar memorias con metadatos como usuario, sesión y marca de tiempo, para luego recuperar un subconjunto filtrado en el momento de la consulta.
Desventaja. El plan en la nube gratuito funciona, pero está limitado a 1 GB de RAM. Al alojarlo uno mismo se elimina ese límite, pero surge la tarea adicional de gestionar y monitorear el propio clúster. La latencia de las consultas también varía según el tamaño del conjunto de datos y la complejidad de los filtros, por lo que es necesario probarlo con la carga de trabajo real del agente.
# Qdrant -- basic similarity search.
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="agent_memory",
vectors_config=VectorParams(size=768, distance=Distance.COSINE),
)
client.upsert(
collection_name="agent_memory",
points=[PointStruct(id=1, vector=[0.1] * 768, payload={"text": "example memory"})],
)
results = client.query_points(
collection_name="agent_memory",
query=[0.1] * 768,
limit=5,
)
La memoria de agente autohospedada en Qdrant es una configuración probada en la actualidad. En el caso de sitios aislados, la desventaja es que aún debe gestionar toda la infraestructura por sí mismo.
3. Weaviate
Weaviate es una base de datos vectorial de código abierto en la que la búsqueda híbrida está integrada en cada consulta, combinando vectores densos con coincidencias de palabras clave mediante BM25.
Nivel gratuito. Weaviate autohospedado es gratuito e ilimitado bajo una licencia BSD-3. Su versión en la nube ofrece actualmente una prueba de 14 días en entorno aislado, con planes de pago posteriormente; por lo tanto, consulte la página de precios para conocer las condiciones actualizadas.
Adecuado para agentes cuando una consulta debe combinar coincidencias de palabras clave con similitud semántica. Un ejemplo es un agente que recupera un recuerdo que debe coincidir tanto con un nombre de entidad exacto como con un concepto vago. Weaviate ofrece estos flujos de trabajo híbridos a través de las API REST y GraphQL.
Patrón de memoria. Memoria de recuperación híbrida. La combinación de BM25 con vectores es la razón principal para elegir Weaviate en lugar de un motor de vectores puro para la recuperación, especialmente cuando la memoria depende tanto de un concepto como de un término exacto.
Desventaja. Para su uso en la nube, la oferta gratuita vence: se trata de una prueba corta y no de un plan permanente. Al alojarlo uno mismo se evita este problema, aunque el costo de la memoria aumenta con el tamaño de los datos, ya que el grafo HNSW se mantiene íntegramente en RAM.
# Weaviate -- basic similarity search.
import weaviate
from weaviate.classes.config import Configure
from weaviate.classes.query import MetadataQuery
client = weaviate.connect_to_local()
memories = client.collections.create(
name="AgentMemory",
vector_config=Configure.Vectors.self_provided(),
)
memories.data.insert(
properties={"text": "example memory"},
vector=[0.1] * 768,
)
response = memories.query.near_vector(
near_vector=[0.1] * 768,
limit=5,
return_metadata=MetadataQuery(distance=True),
)
client.close()
Un agente que debe operar en hardware de borde con recursos limitados, en lugar de en un clúster en la nube siempre conectado, tendrá dificultades para almacenar un índice completo en RAM.
4. Milvus
Milvus es un motor distribuido de código abierto diseñado para colecciones que contienen miles de millones de vectores.
Nivel gratuito. Puedes descargarlo y ejecutarlo tú mismo sin límite de vectores (licencia Apache 2.0). Existen dos modos más ligeros: Milvus Lite para uso local y Standalone para un único nodo. Los clústeres de producción con alta disponibilidad requieren en su lugar una estructura distribuida, lo que implica el uso de Kubernetes, etcd y un almacén de objetos como MinIO. También se admite indexación acelerada por GPU para conjuntos de datos muy grandes.
Es adecuado para agentes cuando la base de conocimientos llegue a cientos de millones de vectores o más, y deseas contar con once o más tipos de índice para ajustar la velocidad de recuperación y el rendimiento según cada colección.
Patrón de memoria. Memoria duradera a una escala muy grande. Se vuelve útil cuando el volumen de datos es lo que ralentiza el almacenamiento en memoria, pero no es adecuado cuando la presión proviene de muchas sesiones o del despliegue en periferia.
Desventaja. El nivel operativo es alto. El modo distribuido no es algo que se adopte para un proyecto secundario; la escalabilidad multi-nodo conlleva una complejidad real, y no es adecuado para hardware en periferia o con recursos limitados.
# Milvus -- basic similarity search.
from pymilvus import MilvusClient
client = MilvusClient(uri="http://localhost:19530", token="root:Milvus")
client.create_collection(collection_name="agent_memory", dimension=768)
client.insert(
collection_name="agent_memory",
data={"id": 1, "vector": [0.1] * 768, "text": "example memory"},
)
results = client.search(
collection_name="agent_memory",
data=[[0.1] * 768],
limit=5,
)
Cuando busque una opción más ligera, considere cuidadosamente la configuración basada en Kubernetes antes de decidirse por ella para búsquedas vectoriales.
5. ChromaDB
ChromaDB es un almacén de vectores de código abierto que puede integrarse en su propio proceso, con casi ningún requisito de configuración.
Nivel gratuito. Es gratuito y no tiene límites en cuanto a vectores, ya sea integrado en un proceso de Python o ejecutándose como contenedor Docker independiente. Según la información del proyecto, no se ofrece ningún servicio en la nube gestionado, aunque ahora podría existir una opción alojada; por lo tanto, consulte el sitio del proyecto.
Es adecuado para agentes cuando el objetivo es realizar experimentos rápidos en una capa de memoria, probando tamaños de bloques, configuraciones de recuperación e instrucciones antes de contar con cualquier infraestructura.
Patrón de memoria. Memoria de trabajo. Adecuada para memorias de corta duración o en etapas de desarrollo dentro de un proceso de agente, pero menos eficaz como almacenamiento a largo plazo que utilicen simultáneamente muchas instancias de agente.
Desventaja. No se ha demostrado su eficacia a gran escala en entornos de producción. La eliminación de elementos no reduce el índice, ya que las operaciones de eliminación en el grafo son costosas y la estructura HNSW solo crece; la fragmentación persiste hasta que el índice se compacta o se reconstruye. Un agente que añade y elimina constantemente memorias acaba teniendo que encargarse de esa limpieza, además de lidiar con los límites de un nodo y la recuperación manual.
# ChromaDB -- basic similarity search.
import chromadb
client = chromadb.PersistentClient(path="./agent_memory")
collection = client.get_or_create_collection(name="agent_memory")
collection.add(
ids=["1"],
embeddings=[[0.1] * 768],
documents=["example memory"],
)
results = collection.query(
query_embeddings=[[0.1] * 768],
n_results=5,
)
Cuando varias instancias de agente necesitan compartir un almacén de memoria, es el modelo incrustado el primero en agotarse. Una solución habitual es un servidor independiente al que se conectan múltiples procesos, y no algo que funcione dentro de un único proceso Python.
6. LanceDB
LanceDB es de código abierto e incrustable: funciona con archivos en almacenamiento de objetos y no requiere ningún proceso servidor.
Nivel gratuito. LanceDB autohospedado o incrustable es gratuito, sin límites de vectores, bajo licencia Apache 2.0. El servicio LanceDB Cloud gestionado sin servidor estaba en beta privada y requería una aplicación cuando se escribió el texto original, por lo que la opción de autohospedaje es la única en la que se puede confiar.
Adecuado para agentes cuando estos se ejecutan en el perímetro o dentro de un flujo de trabajo de ciencia de datos donde un salto de red hacia una base de datos separada es inaceptable, y se desea que el almacén esté en el mismo sistema de archivos que el resto del pipeline.
Patrón de memoria. Memoria periférica y desconectada. El diseño embebido sin servidor se adapta perfectamente a un agente que no puede mantener una conexión estable con un proceso de base de datos.
Desventaja. El modelo embebido que lo hace eficaz en el entorno periférico es también lo que lo limita bajo condiciones de concurrencia. Los sistemas multiagente suelen tener varios procesos escribiendo en una misma tabla al mismo tiempo, lo cual es la carga de trabajo que un almacenamiento dentro del proceso maneja peor. Pruebe ese escenario antes de implementarlo.
# LanceDB -- basic similarity search.
import lancedb
db = lancedb.connect("./agent_memory")
table = db.create_table(
"agent_memory",
data=[{"id": 1, "vector": [0.1] * 768, "text": "example memory"}],
)
results = table.search([0.1] * 768).limit(5).to_list()
7. pgvector
pgvector es una extensión para PostgreSQL que permite a la base de datos que ya se está utilizando realizar búsquedas por similitud vectorial, de modo que no es necesario añadir un sistema nuevo.
Nivel gratuito. La extensión no cuesta nada y es de código abierto. Quienes ya pagan por Postgres la obtienen gratis. Aquellos que no tienen Postgres deben adoptar una base de datos relacional completa solo para poder buscar vectores.
Adecuado para agentes cuando la aplicación ya funciona en Postgres y no sería deseable contar con un segundo almacenamiento exclusivo para la memoria.
Patrón de memoria. La memoria persistente se mantiene dentro de la base de datos principal. Lo que le da ventaja sobre un motor dedicado es la consistencia transaccional, ya que las escrituras en memoria se confirman junto con las filas relacionales de la aplicación.
Desventaja. Las bases de datos vectoriales diseñadas específicamente superan a esta en consultas grandes y filtradas, y no es realista utilizarla en entornos aislados o periféricos a menos que esté dispuesto a ejecutar también una instancia completa de Postgres allí.
# pgvector -- basic similarity search.
import psycopg
from pgvector.psycopg import register_vector
conn = psycopg.connect("dbname=agent_memory")
register_vector(conn)
conn.execute("CREATE EXTENSION IF NOT EXISTS vector")
conn.execute(
"CREATE TABLE IF NOT EXISTS memories (id bigserial PRIMARY KEY, "
"text text, embedding vector(768))"
)
conn.execute(
"INSERT INTO memories (text, embedding) VALUES (%s, %s)",
("example memory", [0.1] * 768),
)
results = conn.execute(
"SELECT text FROM memories ORDER BY embedding <-> %s LIMIT 5",
([0.1] * 768,),
).fetchall()
Si su carga de trabajo requiere un límite de rendimiento que pgvector no puede alcanzar, tendrá que abandonar por completo el modelo Postgres, y ese es el compromiso que debe sopesar.
8. Pinecone
Pinecone funciona como un servicio gestionado y sin servidores, por lo que no puede alojarse por cuenta propia.
Nivel gratuito. La versión Starter ofrece 2 GB de almacenamiento para índices, un máximo de cinco índices, dos millones de unidades de escritura y un millón de unidades de lectura al mes, todo en una sola región de AWS (us-east-1) y para un único proyecto. No existe un límite publicado para los vectores, lo que significa que el almacenamiento será el primer recurso que se agote.
Es adecuado para agentes cuando no desea que nada opere durante la fase de prototipado y está de acuerdo en que la memoria del agente se encuentre íntegramente en la infraestructura de otra persona.
Patrón de memoria. Se agota la memoria al crear prototipos. El plan gratuito está pensado para pruebas y proyectos pequeños, y no es adecuado para el almacenamiento a largo plazo que necesitan los agentes en entornos de producción.
Desventaja. El límite de almacenamiento no es el principal problema para los agentes; lo que sí lo es es la falta de una opción de auto-hospedaje. Si los datos deben permanecer dentro de su infraestructura, Pinecone queda descartado, por más generoso que sea el plan gratuito.
# Pinecone -- basic similarity search.
from pinecone import Pinecone, ServerlessSpec
import os
pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
pc.create_index(
name="agent-memory",
dimension=768,
metric="cosine",
spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)
while not pc.describe_index("agent-memory").status["ready"]:
pass
index = pc.Index("agent-memory")
index.upsert(vectors=[("1", [0.1] * 768, {"text": "example memory"})])
results = index.query(vector=[0.1] * 768, top_k=5)
Una base de datos exclusivamente en la nube simplemente no es una opción para implementaciones cuyas restricciones excluyen por completo los servicios en la nube.
Cómo decidir
Tome la decisión en este orden: dónde se implementará, qué ya está en funcionamiento y cuán grande será.
Dónde se implementará es lo primero, ya que solo ese factor puede vetar por completo una opción. Una base de datos que existe únicamente en la nube no puede colocarse dentro de un sitio aislado, y cuando la normativa exige que los datos permanezcan en su lugar, ningún plan gratuito cambia esa respuesta. Un límite de almacenamiento es simplemente una cifra por la que se paga para poder aumentarla más adelante.
Hay dos consideraciones que no encajan en esa secuencia. Si ya tienes Postgres en tu stack, pgvector te ahorra la necesidad de utilizar una segunda base de datos dondequiera que la implementes. Si buscas escalar a miles de millones de vectores, Milvus es la opción diseñada específicamente para ello desde el principio. Y si solo estás haciendo prototipos, comienza con ChromaDB localmente y pasa a un endpoint alojado cuando realmente lo necesites.
Para implementaciones en entornos locales, aislados o periféricos, la lista realista de opciones son las que se pueden alojar por uno mismo, como VectorAI DB, Qdrant, Milvus, LanceDB y pgvector; la elección entre ellas depende de la escala, las necesidades de concurrencia y la cantidad de trabajo operativo que pueda manejar tu equipo.
Leer más
- Cómo funciona RAG: Embeddings, bases de datos vectoriales y chunking — Sigue a un fragmento de texto desde su tokenización, pasando por el proceso de agrupamiento, hasta la búsqueda mediante similitud coseno, y comprenderás por qué el chunking y los modelos de embeddings determinan la calidad de RAG.
- El significado como coordenadas: de los embeddings a las bases de datos vectoriales y RAG — Una explicación sencilla sobre los embeddings de oraciones, la similitud coseno, las bases de datos vectoriales y el ciclo RAG, con cuatro oraciones cortas sobre perros, gatos y París que ilustran cómo funciona la búsqueda por significado.