Best Vector Database for AI 2026: Pinecone, Qdrant, Chroma

TL;DR + decision tree

• Want the simplest local prototype with no separate database process? Chroma in embedded mode — one pip install chromadb, one PersistentClient(path="./db"), done. Apache-2.0, swap in a server when you outgrow it.
• Want zero operational overhead with a real free tier? Pinecone. Serverless, hosted, 2GB free forever, the SDKs handle batching and retries. Vendor lock-in is the only cost, and the lock-in is shallower than people remember because the data shape is portable.
• Want the best balance of performance, filtering, and OSS licensing? Qdrant. Apache-2.0 Rust server with a filter API so good it’s the reason most teams pick it, plus a generous free Cloud tier and self-host that runs in one binary.
• Want batteries-included vectorization and hybrid search with multi-tenancy as a first-class concept? Weaviate. BSD-3 Go server with vectorizer modules that auto-embed on insert and a hybrid query that fuses BM25 with vector similarity in one call.
• Already running Postgres and want to add vectors without adding a second piece of infrastructure? pgvector. Six distance operators, HNSW or IVFFlat indexes, your existing backups and replication. The cap is 2,000 dimensions on standard-precision indexed vectors.

These five are not substitutes — they sit at different points on a spectrum from “prototype on a laptop” to “production multi-tenant SaaS.” The matrix below makes the trade-offs explicit, then the per-tool sections cover install, code recipe, and skip conditions.

What a vector DB MCP actually does

A vector database is the storage layer for embeddings. An embedding is a list of floating-point numbers (typically 384, 768, 1536, or 3072 dimensions) produced by a model like text-embedding-3-small or BGE — two pieces of text that mean similar things end up with nearby vectors in the embedding space. The job of a vector DB is to answer one query fast: given this query vector, return the k nearest stored vectors. That’s similarity search, and it’s the foundation under retrieval-augmented generation, semantic search, memory systems, recommendation, and most agent-tooling that isn’t pure SQL.

The agent workflow has two phases that map cleanly onto MCP tools:

1. Embed and store (write path). A batch process — or a long-running agent — chunks documents, computes embeddings with a model, and writes (id, vector, metadata) tuples into the database. This is the expensive part: compute, network, and storage all scale linearly with corpus size. You typically do it once per document, then rebuild only when the embedding model changes.
2. Query at runtime (read path). When the agent has a question, it embeds the question with the same model, then asks the vector DB for the top-k nearest stored vectors. The DB returns ids + metadata + (optionally) the raw vector. The agent feeds the retrieved text into the LLM as context. This needs to be fast — typically sub-100ms p99 for a good RAG experience.

A vector DB MCP server wraps these two phases as MCP tools an agent can call. The good ones expose four primitives: create_collection, upsert (write vectors with payload), query (top-k similarity search with filters), and delete. The bad ones expose too many tools — one per knob — which blows the model’s context budget on tool descriptions before the first query even runs. We cover the description-bloat trap in the MCP context bloat fix deep-dive.

A pattern worth naming: most teams write directly to the DB from their application code, then expose only the query path through MCP. That keeps the agent read-only against the corpus and removes a whole class of “the model accidentally deleted my embeddings” bugs. The five MCP servers below all default to giving the agent both paths; restricting to read-only is a config choice on your side, not a per-server feature.

Architectural decision tree

Before the matrix, four binary choices that funnel you toward one or two candidates. Walk these in order.

1. Self-host or SaaS? Pinecone is SaaS only — there is no self-hosted Pinecone, and there will not be one. If your data is bound by a contract or regulation that requires it to stay in your VPC or your on-prem cluster, Pinecone is disqualified. Everyone else in this comparison supports self-host: Chroma as embedded or server, Qdrant as a single binary or Docker, Weaviate as Docker or Kubernetes, pgvector wherever your Postgres runs. Qdrant Cloud and Weaviate Cloud and Chroma Cloud exist for teams that want managed without losing the self-host option later. This first question knocks out roughly half the candidates in most enterprise conversations.

2. Embedded or server? An embedded vector DB runs in the same process as your application — no separate service, no network hop. Chroma inPersistentClient mode is the canonical example; SQLite-style file storage, zero ops. pgvector running on your existing app database is morally embedded (same process boundary as your other DB queries). Server-mode vector DBs (Pinecone, Qdrant, Weaviate, Chroma in server mode) are network services with their own auth and scaling. Embedded is the right answer for prototypes, single-machine agents, and desktop apps; server is the right answer for anything with multiple readers or that needs to survive a process restart. Switching from embedded to server is usually a one-line change in client construction.

3. Vector-only, or hybrid (vector + scalar filters + keyword)? A pure vector query asks “return the k nearest neighbours.” A real production query usually asks “return the k nearest neighbours where the document is from this tenant and the published_date is after 2025-01-01 and the language is ‘en’.” That requires either metadata filtering (all five support this to varying depths) or full hybrid search with BM25 keyword scoring fused into the rank (Weaviate, Qdrant, Pinecone). Chroma’s filter language is functional but shallow. pgvector’s hybrid is whatever you can write in SQL — which is the most powerful and the most manual. If your queries are always vector-only, pick on other axes. If they aren’t, this is where the comparison gets real.

4. Which index type — HNSW or IVFFlat? HNSW (Hierarchical Navigable Small World) is the default in Chroma, Qdrant, Weaviate, and Pinecone’s serverless tier. It gives sub-millisecond query latency at the cost of build time and memory. IVFFlat is the alternative most people first meet through pgvector — fast to build, memory-frugal, recall depends on probe count. The choice matters most for pgvector (you pick at index creation) and Qdrant (where you can configure it per collection); the others default to HNSW and that’s fine for the vast majority of workloads. We cover the trade-offs in more detail in the indexing section below.

Side-by-side matrix

Every cell sourced from the project’s own README/docs/pricing page as of 2026-05-11. Volatile pricing rows verified against pinecone.io/pricing, qdrant.tech/pricing, and weaviate.io/pricing the same week. MCP support rows verified against catalog entries in this directory.

Four takeaways. Only Pinecone is SaaS-only — that’s a 50% knock-out for compliance-bound teams. Only Weaviate ships auto-embedding modules that compute vectors on insert; the other four expect you to embed upstream. Qdrant and Weaviate are the only two with truly first-class hybrid search — Chroma and Pinecone offer narrower filter shapes, and pgvector hybrid is whatever you can express in SQL. pgvector is the only one that piggy-backs on infrastructure you already operate — for teams already running Postgres at scale, this is often the deciding factor.

Chroma — install + recipe

Chroma Working Memorydjm81

1-Click Ready

Chroma Working Memory offers a persistent, searchable 'second brain' for developers with ChromaDB, codebase indexing, an

ai mldeveloper tools5964

What it does best

Chroma wins on time-to-first-query. pip install chromadb, two lines of Python, and you have a working vector store on disk. There is no separate database process to start, no auth to wire, no schema to design — collections are created on demand, the default distance is cosine, and the persistence directory is a folder you can tar and ship. The MCP catalog entry, chroma-working-memory, wraps this surface as an agent-memory tool — perfect for a Claude Code session that needs to remember decisions across turns without standing up real infrastructure. Apache-2.0 licence, no usage limits, no vendor lock-in.

Pick this if you...

• Are prototyping a RAG pipeline and want zero ops overhead while you experiment with chunking and embedding strategies.
• Need an embedded vector store inside a Python application — desktop tool, CLI, single-machine agent — without standing up a network service.
• Want ephemeral or per-session memory for an LLM agent (the chroma-working-memory MCP is built exactly for this pattern).
• Plan to graduate to a server-mode vector DB later and want to start with the option that has the cleanest migration path.

Recipe: working-memory for a Claude Code session

Here is the minimal embed-and-query pattern in pure Python — useful for tests, CLI tools, or as a reference for what the MCP server wraps under the hood:

# pip install chromadb sentence-transformers
import chromadb
from sentence_transformers import SentenceTransformer

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection(
    name="agent_memory",
    metadata={"hnsw:space": "cosine"},
)

embedder = SentenceTransformer("BAAI/bge-small-en-v1.5")

# Write side
notes = [
    "User prefers TypeScript over Python for frontend work.",
    "Project deploys to Vercel, not Cloudflare.",
    "Database is Postgres on Neon, not Supabase.",
]
collection.upsert(
    ids=[f"note_{i}" for i in range(len(notes))],
    documents=notes,
    embeddings=embedder.encode(notes).tolist(),
)

# Read side
query = "what stack does this project use"
hits = collection.query(
    query_embeddings=embedder.encode([query]).tolist(),
    n_results=3,
)
for doc, score in zip(hits["documents"][0], hits["distances"][0]):
    print(f"{score:.3f}  {doc}")

Wire the MCP server from the card above into your Claude Code config and the agent calls these same operations through tool calls instead of Python. The same ./chroma_db folder survives between Claude Code sessions.

Skip it if...

You need production multi-tenancy, hybrid BM25-plus-vector search, or sub-100ms p99 at hundreds of QPS — Chroma was designed for the prototype-and-single-machine end of the spectrum, and operators report mixed experiences scaling it to hundreds of millions of vectors. Move to Qdrant or Pinecone when you outgrow it; the migration is mostly plumbing.

Pinecone — install + recipe

Pinecone Vector DBsirmews

1-Click Ready

Leverage Pinecone vector database for fast semantic search and retrieval augmented generation (RAG) with scalable vector

databasesai ml278

What it does best

Pinecone is the zero-operations choice. The serverless tier auto-scales reads and writes, the SDK handles retries and batching, and the only thing you operate is an index name and a region. The free Starter plan gives 2GB of storage and 1M monthly read units forever — enough to host a real RAG prototype indefinitely. Pinecone Inference (the hosted embedding service) removes the second moving part for teams that don’t already run their own embedding pipeline. The MCP catalog entry, pinecone-vector-db, wraps the query and upsert paths for agent use. The trade-off, of course, is vendor lock-in and SaaS pricing — and there is no self-host option, today or ever.

Pick this if you...

• Want a vector database that someone else operates, monitors, scales, and patches, with a real $0 free tier you can ship to.
• Have bursty traffic — pay-per-read-unit beats over-provisioning a Qdrant VM when QPS varies by 20× across the day.
• Want one vendor for embeddings + storage + retrieval — Pinecone Inference brings the embedding step in-house.
• Are okay budgeting against Pinecone’s usage meters and confident your traffic pattern fits the serverless cost model.

Recipe: upsert and query a Pinecone serverless index

# pip install pinecone openai
from pinecone import Pinecone, ServerlessSpec
from openai import OpenAI

pc = Pinecone(api_key="...")
oai = OpenAI(api_key="...")

# One-time: create the index
if "docs" not in [i.name for i in pc.list_indexes()]:
    pc.create_index(
        name="docs",
        dimension=1536,        # text-embedding-3-small
        metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="us-east-1"),
    )

index = pc.Index("docs")

def embed(texts):
    out = oai.embeddings.create(model="text-embedding-3-small", input=texts)
    return [d.embedding for d in out.data]

# Write side
docs = [
    {"id": "d1", "text": "Pinecone Starter is free up to 2GB."},
    {"id": "d2", "text": "Qdrant Cloud free tier is 0.5 vCPU 1GB."},
]
vectors = [
    {"id": d["id"], "values": v, "metadata": {"text": d["text"]}}
    for d, v in zip(docs, embed([d["text"] for d in docs]))
]
index.upsert(vectors=vectors)

# Read side
q_vec = embed(["what's free with pinecone"])[0]
hits = index.query(vector=q_vec, top_k=3, include_metadata=True)
for m in hits.matches:
    print(f"{m.score:.3f}  {m.metadata['text']}")

Skip it if...

Compliance bans your data from leaving your VPC, or you need self-host for cost reasons at the hundreds-of-millions-of-vectors tier. Pinecone is SaaS-only — no on-prem option exists. Qdrant self-hosted is the closest functional substitute when you need to leave.

Qdrant — install + recipe

Qdrantqdrant

Official1-Click Ready

Qdrant is a powerful vector database for AI systems to store and retrieve vector-based memories with advanced vector sea

ai mldatabases3555

What it does best

Qdrant’s filter API is the single most-cited reason teams pick it. The query language treats metadata filters as first-class — you can express must/should/must_not conditions over scalar fields, ranges, geo points, and even nested payloads, then fuse those with the vector similarity in a single call. Combined with the Apache-2.0 licence, a Rust binary that runs in a single container, and a Cloud free tier (0.5 vCPU / 1GB RAM / 4GB disk, forever), Qdrant covers the broadest sweet spot of any vector DB in this comparison. The official MCP server at /servers/qdrant exposes upsert and similarity-search as agent tools with payload filtering intact.

Pick this if you...

• Need rich metadata filtering — multi-tenant isolation, time-range queries, hierarchical categories — alongside vector similarity.
• Want self-host that runs as one binary or one container, with the option to graduate to managed Cloud without re-architecting.
• Prefer Apache-2.0 source you can audit, fork, or embed in a commercial product without legal review.
• Care about sparse-vector hybrid search and don’t want to bolt on a separate keyword index.

Recipe: upsert with payload, then filter-and-similarity query

# pip install qdrant-client sentence-transformers
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,
)
from sentence_transformers import SentenceTransformer

client = QdrantClient(url="http://localhost:6333")
embedder = SentenceTransformer("BAAI/bge-small-en-v1.5")

client.recreate_collection(
    collection_name="papers",
    vectors_config=VectorParams(size=384, distance=Distance.COSINE),
)

docs = [
    ("p1", "PagedAttention enables KV-cache sharing across requests.", "vllm", 2023),
    ("p2", "HNSW graphs give logarithmic search at high recall.",       "hnsw", 2018),
    ("p3", "Hybrid search fuses BM25 and dense vectors.",                "hybrid", 2024),
]
client.upsert(
    collection_name="papers",
    points=[
        PointStruct(
            id=i,
            vector=embedder.encode(text).tolist(),
            payload={"topic": topic, "year": year, "text": text},
        )
        for i, (pid, text, topic, year) in enumerate(docs)
    ],
)

# Filter + similarity in one call
q = embedder.encode("how does the KV cache work").tolist()
hits = client.search(
    collection_name="papers",
    query_vector=q,
    query_filter=Filter(
        must=[FieldCondition(key="year", match=MatchValue(value=2023))]
    ),
    limit=3,
)
for h in hits:
    print(f"{h.score:.3f}  {h.payload['text']}")

Skip it if...

You want the most batteries-included path — Qdrant asks you to bring your own embedding pipeline (no auto-embed on insert), so if you’d rather the database call OpenAI or Cohere on your behalf, Weaviate or Pinecone Inference will feel friendlier. Skip it too if you’d rather your vectors live inside your existing Postgres than a second piece of infrastructure — pgvector wins on operational surface area in that case.

Weaviate — install + recipe

Weaviateweaviate

Official1-Click Ready

Official Weaviate MCP server. Use Weaviate as a knowledge base for AI agents or as a chat memory store with semantic sea

browser automation4.4k177

What it does best

Weaviate is the batteries-included end of the spectrum. The vectorizer modules (text2vec-openai, text2vec-cohere, text2vec-huggingface, text2vec-jinaai) auto-embed text on insert and on query — you write text, you query text, Weaviate handles the vector math. Hybrid search (BM25 keyword + vector similarity fused with an alpha parameter) is a single method call, not two indexes glued together. Multi-tenancy is first-class: one collection can hold thousands of isolated tenants without separate schemas. BSD-3 licence keeps it commercial-friendly. The official MCP server at /servers/weaviate exposes Weaviate as either a knowledge base or a semantic memory store for an AI agent.

Pick this if you...

• Want hybrid keyword-plus-vector search out of the box, with a single tunable alpha parameter controlling the fusion.
• Don’t want to run an embeddings pipeline yourself — Weaviate’s modules call the embedding provider on your behalf at insert and query time.
• Are building multi-tenant SaaS and want tenants as a first-class concept rather than a row-filter convention.
• Care about generative search — Weaviate can chain retrieval into an LLM call inside the database, useful for some agent patterns.

Recipe: hybrid search across a tenant

# pip install weaviate-client
import weaviate
from weaviate.classes.config import Configure, Property, DataType
from weaviate.classes.query import HybridFusion

client = weaviate.connect_to_local()  # or connect_to_weaviate_cloud(...)

# Schema with auto-embed via text2vec-openai
client.collections.create(
    name="Article",
    vectorizer_config=Configure.Vectorizer.text2vec_openai(),
    multi_tenancy_config=Configure.multi_tenancy(enabled=True),
    properties=[
        Property(name="title", data_type=DataType.TEXT),
        Property(name="body", data_type=DataType.TEXT),
    ],
)

articles = client.collections.get("Article")
articles.tenants.create(["tenant-A", "tenant-B"])

t_a = articles.with_tenant("tenant-A")
t_a.data.insert({"title": "HNSW deep dive", "body": "..."})
t_a.data.insert({"title": "IVFFlat tradeoffs", "body": "..."})

# Hybrid query: 50/50 fusion of BM25 and vector
hits = t_a.query.hybrid(
    query="how does HNSW differ from IVFFlat",
    alpha=0.5,                       # 0 = keyword only, 1 = vector only
    fusion_type=HybridFusion.RELATIVE_SCORE,
    limit=3,
)
for h in hits.objects:
    print(h.properties["title"], h.metadata.score)

Skip it if...

You want the embedding step under your direct control — Weaviate’s vectorizer modules pin you to a module config at collection-creation time and changing embedding providers later is friction. Skip it too if you want the smallest possible operational surface; Qdrant is a tighter binary and pgvector is no extra binary at all.

-- One-time: install the extension and create the table
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
    id           BIGSERIAL PRIMARY KEY,
    org_id       BIGINT NOT NULL,
    title        TEXT NOT NULL,
    body         TEXT NOT NULL,
    embedding    VECTOR(1536),     -- text-embedding-3-small
    created_at   TIMESTAMPTZ DEFAULT now()
);

-- HNSW index (better query latency, slower build)
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Write side (from Python, with embeddings computed upstream)
-- INSERT INTO documents (org_id, title, body, embedding)
--    VALUES ($1, $2, $3, $4);

-- Read side: top-3 nearest WHERE org matches, cosine distance
SELECT id, title, 1 - (embedding <=> $1) AS similarity
  FROM documents
 WHERE org_id = $2
 ORDER BY embedding <=> $1
 LIMIT 3;

Indexing & query performance

Vector search at any meaningful scale is approximate. Exact nearest-neighbour search means computing the distance from your query vector to every stored vector and sorting — fine for ten thousand vectors, intractable for ten million. Approximate algorithms trade a small drop in recall (you might miss the absolute top neighbour some fraction of the time) for orders-of-magnitude speedup. Two algorithms dominate the consumer side: HNSW and IVFFlat.

HNSW (Hierarchical Navigable Small World) builds a layered graph. Each vector is a node; higher layers have fewer nodes and longer connections; lower layers have all nodes with shorter connections. Search descends the layers greedily — find the rough neighbourhood at the top, refine at the bottom. The practical knobs are M (number of connections per node, typically 16) and ef_construction (search width during build, typically 64-200). HNSW gives sub-millisecond queries at high recall, at the cost of build time (slower than IVFFlat) and memory (the graph itself takes space). It’s the default in Chroma, Qdrant, Weaviate, and Pinecone’s serverless tier for a reason: for read-heavy RAG workloads, the trade-off lands in HNSW’s favour the vast majority of the time.

IVFFlat (Inverted File Flat) partitions the vector space into clusters (Voronoi cells) using k-means at index build time, then at query time scans only the clusters nearest to the query. The knob is probes — how many clusters to inspect. More probes means higher recall but slower queries; fewer probes means faster queries but more chance of missing the right answer. IVFFlat builds much faster than HNSW (the centroids are fixed, no graph to construct) and uses less memory. It’s the pragmatic choice when your workload is write-heavy, the index needs to rebuild frequently after large inserts, or you’re memory-constrained. pgvector exposes both; Qdrant defaults to HNSW but can be configured otherwise.

What the published benchmarks actually say. Qdrant’s public benchmarks page (qdrant.tech/benchmarks) is the only first-party comparison published by any of these vendors. The headline framing — “Qdrant achieves highest RPS and lowest latencies in almost all the scenarios” — is genuine for the datasets and configurations they tested, but the exact numbers depend heavily on dataset (1M GIST-1M is very different from 100M deep-image), hardware, and the specific build of the competitor. The page also notes Elasticsearch “can be 10x slower when storing 10M+ vectors,” Milvus is fastest at indexing time but trails on query latency at higher dimensions, and Weaviate “improved the least since our last run.” Read it as informed directional signal from one of the players, not an impartial leaderboard. The right benchmark for your team is the one you run on your own corpus, on your own hardware, with your own embedding model — anything else is marketing dressed up as data.

Recall vs latency is a real trade-off. Bumping HNSW’s ef_search from 64 to 256 typically doubles latency and adds a few points of recall. Whether those few points matter depends on your task: for RAG over a small curated corpus, recall@10 of 0.95 may be plenty because the LLM tolerates noisy retrieval; for legal discovery or medical retrieval where missing a relevant document is costly, you want 0.99+. Tune ef_search per workload rather than accepting the default — this is the single biggest knob nobody documents adequately.

Quantization changes the math again. Once your corpus crosses tens of millions of vectors, storing them at full float32 precision becomes the dominant cost. Qdrant, Weaviate, and Pinecone all support scalar quantization (compress each dimension to int8 — 4x storage saving, modest recall loss) and product quantization (compress groups of dimensions jointly — 16-32x saving, more recall loss). pgvector supports half-precision and binary quantization on the column type itself. The right knob to reach for at scale is rarely “a bigger machine” — it’s “quantize the vectors and measure the recall delta.” A production system running 200M vectors at int8 with 95% recall almost always beats the same system running 50M vectors at float32 with 97% recall, because the LLM downstream can absorb the noise but the budget cannot absorb the storage cost.

Dimension matters more than people expect. Higher-dimensional vectors aren’t strictly better — they cost more to store, more to compare, and the curse of dimensionality eventually makes distances less discriminative. The current sweet spot for general-purpose English RAG sits between 384 dimensions (BGE-small, GTE-small) and 1,536 dimensions (text-embedding-3-small). Below 384, retrieval quality drops sharply; above 1,536, you’re paying more for marginal gains and bumping into pgvector’s 2,000-dimension index cap. Pick your embedding model based on retrieval quality on your evaluation set, not on dimension count.

Pricing shape

The libraries and binaries are all free. The managed offerings are not. Numbers below are pulled from each vendor’s public pricing page on 2026-05-11 — treat as a snapshot.

Treat dollar amounts above as approximate — pricing pages update frequently and serverless meters change independent of headline tiers. Always confirm before you commit: pinecone.io/pricing, qdrant.tech/pricing, weaviate.io/pricing. Chroma Cloud’s pricing is documented at docs.trychroma.com; pgvector inherits its hosting cost from whichever Postgres provider you use.

Common pitfalls

Migration paths

One advantage of the vector DB space: data shapes are similar enough that switching is mostly plumbing. A vector plus a payload plus an id maps cleanly between every system in this comparison; the migration cost is code, not modelling. Three patterns recur.

Chroma → Qdrant or Pinecone. Almost always because the team has graduated past prototype into something with multiple readers, multi-tenant isolation requirements, or scale expectations. The migration is an export loop from Chroma’s persistent client (collection.get(include=["embeddings", "metadatas", "documents"])) into a bulk upsert against the target. Check the distance metric matches (Chroma defaults to cosine; Qdrant’s default is also cosine if you set Distance.COSINE). Allow a couple of hours of upsert time per million vectors; rebuild indexes after the bulk load.

Pinecone → self-hosted (usually Qdrant). Almost always because the bill grew faster than expected or compliance changed. The escape path is straightforward — Pinecone’s fetch and list APIs let you read every vector and namespace, and Qdrant’supsert takes the same data shape. The hidden friction is operational: you now own a database, with backups, monitoring, and patching. Most teams that make this switch also acquire a platform engineer in the same quarter. Run both side-by-side for a few weeks before flipping traffic.

pgvector → dedicated vector DB. The trigger is usually one of three: vectors above 2,000 dimensions outgrowing indexed-column limits, contention between OLTP and vector workloads in the shared buffer pool, or operational pressure to separate concerns. The migration is a sequential read from Postgres (SELECT id, embedding, metadata FROM documents) into a bulk upsert against the target. Dual-write during the cutover so reads can fail back, then verify recall on a holdout set before flipping the read path. The relational data stays in Postgres; only the vector column moves.

Notice what isn’t a common migration: Weaviate → anywhere. Weaviate’s schema-and-vectorizer model captures more state than the other systems, so migrations out of Weaviate usually require recomputing embeddings against a different model rather than copying vectors verbatim. If you start on Weaviate, plan to stay on Weaviate; the lock-in is real but well-priced for what you get.

The most underrated migration is the simplest: staying put and tuning. Teams routinely blame the database when the real culprit is an unindexed payload field, an undertuned ef_search, or an embedding model swapped without rebuilding the index. Before migrating, run an evaluation set against your current store with the knobs explicit (M, ef_construction, ef_search for HNSW; lists and probes for IVFFlat) and measure recall and latency. About half the time, the migration cancels itself because the existing system was fine once configured properly.

Community signal

Three voices that capture why developers reach for different parts of this matrix. Verbatim from the cited sources.

Frequently asked questions

Sources

Chroma

• github.com/chroma-core/chroma — Apache-2.0 source
• docs.trychroma.com — embedded/server modes, Chroma Cloud
• /servers/chroma-working-memory — MCP catalog entry

Pinecone

• pinecone.io/pricing — Starter / Builder / Standard / Enterprise tiers
• docs.pinecone.io — serverless, Pinecone Inference, sparse-dense indexes
• /servers/pinecone-vector-db — MCP catalog entry

Qdrant

• github.com/qdrant/qdrant — Apache-2.0 Rust source
• qdrant.tech/benchmarks — first-party benchmark methodology
• qdrant.tech/pricing — Cloud free / Standard / Premium tiers
• /servers/qdrant — MCP catalog entry

Weaviate

• github.com/weaviate/weaviate — BSD-3 Go source
• weaviate.io/developers/weaviate — vectorizer modules, hybrid search, multi-tenancy
• weaviate.io/pricing — Flex / Premium tiers
• /servers/weaviate — MCP catalog entry

pgvector

• github.com/pgvector/pgvector — PostgreSQL-licence source, six distance operators, HNSW + IVFFlat
• postgresql.org/docs/current — Postgres backups, replication, full-text search (companion infra for hybrid)
• /servers/postgres — generic Postgres MCP that works with pgvector

Related comparisons

• /blog/mem0-vs-letta-vs-zep-vs-cognee-2026 — memory frameworks built on top of these stores
• /blog/best-knowledge-base-mcp-servers-2026 — curated knowledge-base MCP roundup
• /blog/langgraph-vs-crewai-vs-letta-vs-autogen-2026 — agent frameworks that consume these stores
• /blog/mcp-context-bloat-fix-2026-tool-search-code-mode-progressive-disclosure — keeping tool descriptions lean across many MCP servers

Internal links

• /servers/chroma-working-memory
• /servers/pinecone-vector-db
• /servers/qdrant
• /servers/weaviate
• /servers/postgres
• /blog/what-is-mcp — protocol primer
• /best-mcp-servers — curated roundup
• /servers — browse all 3,000+