8 Best Free Vector Databases for AI Agents in 2026

The best free vector databases for AI agents in 2026 are Actian VectorAI DB Community Edition, Qdrant, Weaviate, Milvus, ChromaDB, LanceDB, pgvector, and Pinecone. All eight are free to start, but free to start doesn't equate to free to use at scale, and also not the same as deployable where your agent runs.

An agent needs more from a vector database than a one-off Retrieval-Augmented Generation (RAG) pipeline does. It reads and writes memory across sessions, so what matters is whether that memory survives a restart, how latency holds up under concurrent calls, and whether the database runs where the agent runs, including hardware with no reliable network.

A free tier will not answer all of that. Testing latency under real concurrency usually means paying for a plan big enough to generate the load. But a free tier does tell you where each vendor draws its lines, and some of those lines rule an option out before you write any code. One deletes your cluster after 14 days. Another has no self-hosted option, so it is out if your data cannot leave your infrastructure. Every entry in this guide states its limit plainly, and you leave with a clear recommendation for your deployment and an honest picture of what each option gives up.

TL;DR

This chart showcases the results at a birds eye view.

How We Evaluated These Databases

We evaluated eight vector databases on five criteria that matter specifically for AI agents: free tier type, agent memory pattern supported, query latency under load, on-premises viability, and honest free tier limits.

Most vector database comparisons are written for RAG pipelines or recommendation systems, where the database sits behind a stateless API call and gets rebuilt from a fixed corpus. Agents are different. An agent accumulates memory across sessions, so the database needs to persist state, not just serve queries. That changes which criteria matter and which trade-offs are acceptable.

• Free tier type. Fully self-hostable with no vector limits, a managed free tier with a vector or storage cap, or a library rather than a database.

• Agent memory pattern supported. Which memory architecture pattern the database enables for an agent.

• Query latency under load. How the database performs when multiple agent calls arrive at once.

• On-premises viability. Whether the database can run entirely on your own infrastructure with no cloud dependency.

• Free tier limit. What breaks, or starts costing money, when you scale past the free tier.

Every entry below is free to start, but each one comes with certain trade-offs.

The 8 Best Free Vector Databases for AI Agents

1. VectorAI DB Community Edition

VectorAI DB is a self-hosted vector database, built to run the same way from a laptop to an air-gapped production environment.

Free tier: Community Edition is self-hosted and capped at 5,000 vectors, the smallest hard cap on this list. A separate 30-day trial raises the ceiling to one million vectors. It ships as a single Docker container with no external dependencies such as Kubernetes, etcd, or object storage. On performance, Actian's April 2026 benchmark reports 745.2 QPS at 10 million vectors and 768 dimensions on a 64GB self-hosted machine (HNSW m=32, ef_construction=512, ef_search=512), a 22x QPS advantage over Milvus and Qdrant Local on identical hardware. That figure is Actian's own, and it measures the paid engine at 10 million vectors, not the 5,000-vector Community Edition.

Best for agents when: Your agent needs to run where the data lives rather than where a cloud provider has a data center: air-gapped facilities, environments with strict data-residency requirements, edge hardware including NVIDIA Jetson and Raspberry Pi, or any deployment where cloud egress is itself the constraint. Actian describes the product as offering compliance-ready configurations for customer-built applications, which is a statement about what you can build on it, not a certification that ships with the free tier.

Agent memory pattern: Edge and disconnected memory, plus persistent agent memory. The collection persists to disk and survives restarts, and the single-container model is what makes both the edge and air-gapped cases workable without a Kubernetes stack.

Limitation: Community Edition is self-hosted only. There is no managed free cloud tier as Pinecone and Qdrant Cloud offer, so if zero infrastructure management is the actual requirement, this is not the right fit.

# 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 a Rust-native, open-source vector database. You can self-host it with no vector limits or run it on Qdrant Cloud.

Free tier: Self-hosted Qdrant is free, with no caps, and licensed under Apache 2.0. Qdrant Cloud's free tier is a permanent single-node cluster with 0.5 vCPU, 1 GB RAM, and 4 GB disk, which fits roughly one million vectors at 768 dimensions.

Best for agents when: Your agent needs fast, filtered retrieval in production and you want an engine with client libraries across Python, TypeScript, Rust, Go, Java, and .NET.

Agent memory pattern: Persistent agent memory. Qdrant's payload filtering combined with vector search supports an agent that stores memories with metadata filtering for fields like user, session, and timestamp, then retrieves a filtered subset at query time.

Limitation: The cloud free tier is usable but still capped at 1 GB RAM. Self-hosting removes the cap but adds the ops overhead of running and monitoring your own cluster, and query latency varies by dataset size and filter complexity, so test performance 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,
)

Qdrant already runs a self-hosted agent memory today. If your deployment is air-gapped, the key limitation is that Qdrant still expects you to operate the infrastructure yourself. VectorAI DB is positioned differently for that case because it runs as a single-container deployment without Kubernetes.

3. Weaviate

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

Free tier: Self-hosted Weaviate is free with no limits under a BSD-3 license. Weaviate Cloud currently offers a 14-day sandbox trial, and paid plans start after that period. Check Weaviate’s pricing page for the latest details.

Best for agents when: A single query needs to combine keyword matching and semantic similarity, such as an agent retrieving a memory that must match both an exact entity name and a fuzzy concept, and Weaviate exposes these hybrid retrieval workflows through REST and GraphQL APIs.

Agent memory pattern: Hybrid retrieval memory. The BM25 plus vector combination is the main reason to pick Weaviate over a pure vector engine for agent recall. That matters most when a memory depends on both a semantic concept and an exact term.

Limitation: If you want a cloud-hosted option, there is no persistent free tier anymore, only a time-boxed trial. Self-hosting avoids that, but the HNSW index lives entirely in memory, which becomes expensive at scale.

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

If your agent needs to run on constrained edge hardware rather than an always-connected cloud cluster, VectorAI DB is the more practical option because it avoids keeping the full HNSW index in memory.

4. Milvus

Milvus is an open-source, distributed vector database. It is built for billion-scale vector workloads

Free tier: Self-hosted Milvus has no vector limits under Apache 2.0. It ships in two modes: Milvus Lite for local development and Standalone for a single-node deployment. Production-scale, high-availability deployments need the Distributed architecture, which adds Kubernetes, etc, and object storage such as MinIO to the stack. Milvus supports GPU indexing for acceleration at massive scale.

Best for agents when: Your agent operates against a knowledge base that reaches into the hundreds of millions or billions of vectors, and you need 11+ index types to tune the recall and speed trade-off per collection.

Agent memory pattern: Persistent agent memory at scale. Milvus is the right pattern when the agent's memory store is the bottleneck at large data volumes, not when session count or edge deployment is the constraint.

Limitation: The operational floor is high. Distributed mode is not something you stand up for a side project. Multiple-node scaling adds operational complexity, and Milvus is not suitable for 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,
)

If you need a lighter deployment than Milvus, compare it with VectorAI DB, which has lower operational overhead, before committing to a Kubernetes-based setup for vector search.

5. ChromaDB

ChromaDB is an open-source, embedded vector database that runs with near-zero configuration.

Free tier: ChromaDB is free with no vector limits, whether you run it embedded in a Python process or as a standalone Docker container. There is no separate paid tier to compare against because the project does not sell a managed cloud service like the other entries here.

Best for agents when: You are prototyping an agent's memory layer and want to iterate on chunking, retrieval, and prompt design without standing up any infrastructure first.

Agent memory pattern: Working memory. ChromaDB works well for a single-process agent's short-lived or development-time memory, but it is a weaker fit for durable stores that multiple agent instances read from concurrently.

Limitation: ChromaDB is not production-hardened at scale. Deletes do not shrink the index: Chroma's HNSW growth is unbounded by design because graph removals are expensive, so deleted vectors leave fragmentation behind, and the index must be compacted or rebuilt to reclaim space. For an agent that continuously writes and evicts memories, that is a maintenance job you own, alongside single-node scaling limits and manual recovery.

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

If several agent instances need to read and write to one memory store, the embedded model is what runs out first: VectorAI DB runs as a standalone server that multiple agent processes connect to concurrently instead of living inside a single Python process.

6. LanceDB

LanceDB is an open-source, embedded vector database that runs directly on object storage with no separate server process.

Free tier: LanceDB is free with no vector limits when self-hosted or embedded, licensed under Apache 2.0. The managed serverless option, LanceDB Cloud, is in private beta and requires an application, so self-hosting is the only path you can count on today.

Best for agents when: Your agent runs at the edge or in a data science workflow where a network round trip to a separate database process is not acceptable, and you want the vector store to live in the same file system as the rest of your pipeline.

Agent memory pattern: Edge and disconnected memory. LanceDB's embedded, no-server design maps directly onto an agent that cannot assume a persistent network connection to a database process.

Limitation: The embedded model that makes LanceDB good at the edge is the same thing that constrains it under concurrency. Multi-agent systems usually have several processes writing to the same table at once. That is the workload an in-process store handles worst, so test that path before you commit.

# 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 a PostgreSQL extension that adds vector similarity search and vector support to a database you may already be running, rather than replacing Postgres with a separate system.

Free tier: pgvector itself is free and open source. If you already pay for Postgres hosting, the extension costs nothing extra. If you do not already run Postgres, you are taking on a full relational database just to get vector search.

Best for agents when: Your agent's application logic already lives on a Postgres stack, and you want to avoid introducing a second database purely for memory storage.

Agent memory pattern: Persistent agent memory, integrated. The advantage over a dedicated vector database is transactional consistency: an agent's memory writes commit alongside the rest of the application's relational data in the same transaction.

Limitation: Purpose-built vector databases outperform pgvector on large-scale filtered queries, and it is not a realistic option for air-gapped or edge deployments unless you are willing to run a full Postgres instance in that environment 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 to run at a performance ceiling pgvector cannot reach without leaving the Postgres model entirely, VectorAI DB's comparison once you drop the Postgres dependency lays out that trade-off in more depth.

8. Pinecone

Pinecone is a fully managed, serverless vector database with no self-hosted option.

Free tier: The Starter plan includes 2 GB of index storage, up to five indexes, two million write units a month, and one million read units a month, restricted to a single AWS region (us-east-1) and one project. Pinecone publishes no permanent vector count, so storage is the actual constraint.

Best for agents when: You want zero infrastructure to manage while prototyping, and you are comfortable with your agent's memory living entirely outside your own infrastructure.

Agent memory pattern: Working memory for prototyping. The free tier is sized for evaluation and small projects, not for an agent's durable, growing memory store in production.

Limitation: The biggest limitation for agents specifically is not the storage cap; it is that there is no self-hosted option at all. If your deployment constraint is that data cannot leave your infrastructure, Pinecone is disqualified regardless of the free tier's generosity.

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

If your agent's deployment constraint rules out a cloud-only database entirely, the self-hosted case against Pinecone walks through exactly where that line gets drawn.

How to Choose

Choose in this order: deployment environment, existing infrastructure, then scale.

Deployment environment comes first because it is the only one of the three that can disqualify an option outright. A cloud-only database cannot be argued into an air-gapped facility, and in a regulated environment where data residency is the requirement, no free tier is generous enough to change that. A storage cap, by contrast, is just a number you eventually pay to raise.

Figure 1: Decision path from deployment target to recommended database

Two considerations sit outside that tree. If you are already running Postgres, pgvector avoids standing up a second database, no matter where you deploy. If you are building toward billion-vector scale, Milvus is the one designed for it from the start. And if you are prototyping, start with ChromaDB locally and move to a hosted endpoint only when you actually need one.

If your deployment needs to run on-premises, air-gapped, or at the edge, try VectorAI DB Community Edition via Docker pull.