Eight Free Vector Databases for AI Agents Compared: Limits, Fit and Trade-offs

Eight vector databases come up again and again when people build agents on a budget: VectorAI DB Community Edition, Qdrant, Weaviate, Milvus, ChromaDB, LanceDB, pgvector and Pinecone. Each is free to begin with. That's a different thing from free at scale, and a different thing again from deployable wherever the agent has to run.

Agents lean on a vector store harder than a single RAG pipeline ever does. Their memory is written and read again and again over many sessions. So you need to know if that memory outlives a restart, how response times behave when calls overlap, and if the engine can sit next to the agent, even on a device with a flaky or absent connection.

A free tier can't settle all of that. To see how latency holds up under genuine concurrent load you typically need a paid plan large enough to produce that load. Still, free tiers do reveal where each vendor draws its lines, and some of those lines eliminate an option before any code is written. One service deletes an idle cluster after 14 days. Another has no self-hosted version, which rules it out if data can't leave your infrastructure. Each entry below states its limit plainly, so you can match a database to your deployment and see what you'd be giving up. Limits, caps and prices change often, so confirm the current numbers on each vendor's own pricing page before committing.

Criteria

Eight databases were compared on five points that matter for agents specifically.

• Kind of free tier. Fully self-hostable with no vector cap, a managed free plan with a storage or vector limit, or a library and not a database.
• Memory pattern it suits. Which agent memory design the database makes easy.
• Latency under load. How it behaves when several agent calls land together.
• On-premises viability. Whether it can run entirely on your own machines with no cloud dependency.
• What breaks past the free tier. The point where something fails or starts costing money.

Most published comparisons are aimed at RAG or recommendation workloads, in which the database answers stateless requests and gets rebuilt from a fixed set of documents. Agents differ because they accumulate memory across sessions. The store has to persist state and not just answer queries, which changes which trade-offs are acceptable.

The eight, one by one

1. VectorAI DB Community Edition

VectorAI DB is a vector database you run yourself, designed to work identically on a developer laptop and in a disconnected production site.

Free tier. The Community Edition is self-hosted and capped at 5,000 vectors, the smallest hard limit here. A separate 30-day trial reportedly raises the ceiling to one million. It ships as a single Docker container with no outside dependencies such as Kubernetes, etcd or object storage. Its maker has published benchmark results claiming around 745 queries per second at 10 million 768-dimension vectors on a 64 GB machine, and a 22x lead over Milvus and Qdrant Local on the same hardware. Treat that as a vendor claim: it describes the paid engine at 10 million vectors and not the 5,000-vector free edition.

Suits agents when the agent must run where the data sits and not where a cloud provider has a data centre: air-gapped sites, strict data-residency rules, edge hardware such as NVIDIA Jetson and Raspberry Pi, or anywhere cloud egress is itself the problem. The vendor describes compliance-ready configurations for applications you build on top, which is not the same as a certification that comes with the free edition.

Memory pattern. Memory for edge and offline agents, along with durable memory in general. Data goes to disk and comes back after a restart, and having just one container to run is what keeps offline and air-gapped use practical when Kubernetes is off the table.

Drawback. You host it yourself, full stop. No free managed cloud plan exists, unlike Pinecone or Qdrant Cloud, so a team that wants nobody to run servers should choose differently.

# 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 is an open-source vector database written in Rust. You can host it yourself without vector limits or run it on Qdrant Cloud.

Free tier. Run it on your own hardware and Qdrant costs nothing and has no ceiling (Apache 2.0). On Qdrant Cloud, the no-cost plan gives a lasting single node with half a vCPU, 1 GB of memory and 4 GB of storage, roughly enough for a million vectors of 768 dimensions.

Suits agents when you need quick, filtered retrieval in production and want client libraries for Python, TypeScript, Rust, Go, Java and .NET.

Memory pattern. Persistent agent memory. Payload filtering combined with vector search lets an agent store memories with metadata such as user, session and timestamp, then fetch a filtered subset at query time.

Drawback. The free cloud plan works but stays capped at 1 GB of RAM. Self-hosting lifts the cap and adds the operational chore of running and monitoring your own cluster. Query latency also shifts with dataset size and filter complexity, so test against the agent's real workload.

# 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,
)

Self-hosted agent memory on Qdrant is a proven setup today. For air-gapped sites the catch is that you still operate all the infrastructure yourself.

3. Weaviate

Weaviate is an open-source vector database in which hybrid search is built into every query, mixing dense vectors with BM25 keyword matching.

Free tier. Self-hosted Weaviate is free and unlimited under a BSD-3 licence. Its cloud offering currently gives a 14-day sandbox trial, with paid plans afterwards, so check the pricing page for up-to-date terms.

Suits agents when one query has to combine keyword matching with semantic similarity. An example is an agent recalling a memory that must match an exact entity name and a fuzzy concept together. Weaviate offers these hybrid workflows through REST and GraphQL APIs.

Memory pattern. Hybrid retrieval memory. Pairing BM25 with vectors is the main reason to choose Weaviate over a pure vector engine for recall, especially when a memory hinges on both a concept and an exact term.

Drawback. For hosted use, the free offer expires: it's a short trial and not a standing plan. Hosting it yourself sidesteps that, though memory cost climbs with data size because the HNSW graph is kept wholly in 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()

An agent that must live on constrained edge hardware, instead of an always-connected cloud cluster, will find an index held fully in RAM hard to accommodate.

4. Milvus

Milvus is an open-source, distributed engine aimed at collections that reach into the billions of vectors.

Free tier. Download and run it yourself with no vector cap (Apache 2.0). Two lighter modes exist, Milvus Lite for local work and Standalone for one node. Highly available production clusters need the distributed layout instead, bringing in Kubernetes, etcd and an object store like MinIO. GPU-accelerated indexing is also supported for very large datasets.

Suits agents when the knowledge base will hit hundreds of millions of vectors or more, and you'd like a choice of eleven or more index types so recall and speed can be tuned for each collection.

Memory pattern. Durable memory at very large scale. It earns its place when data volume is what slows the memory store down, and it's the wrong fit when the pressure comes from many sessions or from edge deployment.

Drawback. The operational floor is high. Distributed mode isn't something you stand up for a side project, multi-node scaling brings real complexity, and it doesn't suit edge or constrained hardware.

# 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,
)

When you want something lighter, weigh the Kubernetes-based setup carefully before committing to it for vector search.

5. ChromaDB

ChromaDB is an open-source vector store you embed in your own process, with hardly any setup.

Free tier. It's free with no vector limits, whether embedded in a Python process or run as a standalone Docker container. The source material claims the project sells no managed cloud service, though a hosted offering may exist by now, so check the project's site.

Suits agents when the goal is quick experiments on a memory layer, trying chunk sizes, retrieval settings and prompts before any infrastructure exists.

Memory pattern. Working memory. Fine for short-lived or development-stage memory inside one agent process, weaker as a long-lived store that many agent instances use simultaneously.

Drawback. It hasn't been proven at large production scale. Removing items doesn't shrink the index, since graph deletions are expensive and the HNSW structure only grows; fragmentation stays until the index is compacted or rebuilt. An agent that constantly adds and evicts memories ends up owning that cleanup, plus the limits of one node and recovery by hand.

# 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,
)

When several agent instances need to share one memory store, the embedded model is what runs out first. A standalone server that multiple processes connect to is the usual answer, and not something living inside one Python process.

6. LanceDB

LanceDB is open source and embedded: it works on files in object storage and needs no server process at all.

Free tier. Self-hosted or embedded LanceDB is free, with no vector limits, under Apache 2.0. The managed serverless LanceDB Cloud was in private beta and required an application when the source was written, so self-hosting is the only path you can rely on.

Suits agents when the agent runs at the edge or inside a data science workflow where a network hop to a separate database is unacceptable and you want the store to sit on the same filesystem as the rest of the pipeline.

Memory pattern. Edge and disconnected memory. The embedded, serverless design maps neatly onto an agent that can't assume a steady connection to a database process.

Drawback. The embedded model that makes it strong at the edge is also what constrains it under concurrency. Multi-agent systems often have several processes writing to one table at once, which is the workload an in-process store handles worst. Test that path before committing.

# 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 is an extension for PostgreSQL that gives a database you may already operate the ability to search by vector similarity, so Postgres stays and no new system is added.

Free tier. The extension costs nothing and is open source. Anyone already paying for Postgres gets it for free. Anyone without Postgres has to adopt an entire relational database simply to search vectors.

Suits agents when the application already runs on Postgres and a second datastore just for memory would be unwelcome.

Memory pattern. Durable memory kept inside the main database. What it gains over a dedicated engine is transactional consistency, since memory writes commit alongside the application's relational rows.

Drawback. Purpose-built vector databases outperform it on large filtered queries, and it's not realistic for air-gapped or edge deployments unless you're prepared to run a full Postgres instance there too.

# 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()

If your workload needs a performance ceiling that pgvector can't reach, you'll have to leave the Postgres model entirely, and that's the trade-off to weigh.

8. Pinecone

Pinecone runs as a managed, serverless service, and you cannot host it yourself.

Free tier. Starter gives 2 GB of index storage, five indexes at most, two million write units and one million read units each month, all in a single AWS region (us-east-1) and one project. There's no published vector limit, which means storage is what you'll hit first.

Suits agents when you'd like nothing to operate during prototyping and are fine with the agent's memory sitting entirely on someone else's infrastructure.

Memory pattern. Scratch memory while prototyping. The free plan is meant for trials and small projects and doesn't suit an agent's growing long-term store in production.

Drawback. The storage cap isn't the main problem for agents. The absence of any self-hosted option is. If data must stay inside your infrastructure, Pinecone is disqualified however generous the free plan.

# 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)

A cloud-only database is simply not an option for deployments whose constraints rule out cloud services altogether.

How to decide

Decide in this order: where it deploys, what you already run, and how big it will get.

Where it deploys comes first, because only that factor can veto a choice completely. A database that exists only in the cloud can't be placed inside an air-gapped site, and when regulation demands data stay put, no free plan changes the answer. A storage cap is merely a figure you pay to lift later.

Two considerations fall outside that sequence. If Postgres is already in your stack, pgvector spares you a second database wherever you deploy. If you're heading toward billion-vector scale, Milvus is the one built for it from the start. And if you're only prototyping, begin with ChromaDB locally and move to a hosted endpoint when you genuinely need one.

For on-premises, air-gapped or edge deployments, the realistic shortlist is the self-hostable options, namely VectorAI DB, Qdrant, Milvus, LanceDB and pgvector, and the choice among them comes down to scale, concurrency needs and how much operational work your team can carry.