Top 5 Vector Databases for RAG (and Where Sanity Context Fits Instead)

Every "best vector database for RAG" list ranks the same plumbing: Pinecone, Weaviate, pgvector, and friends. They're good at storing vectors. They're terrible at being the source of truth your agent is supposed to answer from. The moment your content changes, the index drifts, and your agent confidently cites last quarter's docs. This list ranks five vector databases honestly, then explains why the better question isn't "which vector store?" but "where does retrieval live?" Spoiler: inside the content, with Sanity Context.

Sanity Context is Sanity's agent-facing product, and its Context MCP endpoint does retrieval differently: GROQ queries against live schema, no index to drift, no stale embeddings to debug.

1. Pinecone, the managed default everyone reaches for first

Pinecone is the path of least resistance for teams shipping their first RAG prototype. It's a fully managed vector database, so you don't run infrastructure, tune HNSW parameters, or babysit shards, you push embeddings and query them. For pure nearest-neighbour search at scale it's hard to fault, and the developer experience is genuinely clean. The catch is that Pinecone only knows about vectors. It has no idea what your content means, whether it's published or in draft, or whether the source document was edited five minutes ago. You own the entire pipeline that turns content into embeddings, re-embeds on every change, and keeps the index in sync with the system of record. That sync gap is where agents start hallucinating: the vector store says one thing, the live content says another, and nobody owns the reconciliation. Pinecone is an excellent component. It is not a content backend, and treating it like one is how RAG projects quietly rot in production.

2. Weaviate, open-source flexibility with hybrid search built in

Weaviate earns its place because it ships hybrid search natively, combining dense vector similarity with keyword (BM25) scoring in a single query, rather than bolting one onto the other. That matters for RAG, because pure semantic search misses exact matches like error codes, SKUs, and version numbers, while pure keyword search misses paraphrase. Weaviate's modules and self-hostable core also make it attractive to teams who want control and to avoid per-vector pricing. The trade-off is operational: you're now running a database, designing its schema, and writing the ingestion layer that pulls from wherever your content actually lives. Weaviate solves the retrieval-blending problem well, but it sits downstream of your content. You still maintain a separate pipeline to keep it populated and current, and the schema in Weaviate is a second model of content that has to be kept honest against the first. Powerful, but it's another system to own, not a reduction in moving parts.

3. pgvector / Neon, keep vectors next to your relational data

pgvector turns Postgres into a vector store, and that's a genuinely smart move for teams who already run Postgres. Your embeddings sit beside your application data, you query them with SQL, and you avoid standing up a whole new system. Neon and similar serverless Postgres hosts make this nearly frictionless to start. For RAG over data that already lives in your database, orders, users, structured records, it's pragmatic and cheap. But pgvector is a column type, not a content platform. It does nothing to model rich content, handle drafts versus published state, or give editors any way to see or govern what the agent retrieves. You still write the embedding pipeline, the chunking strategy, and the re-index logic by hand. And hybrid retrieval, combining keyword and semantic relevance, is something you stitch together with extensions and SQL rather than getting as a first-class primitive. It's the most economical entry point on this list and the one with the least content awareness.

4. Upstash / Supabase Vector, serverless vectors for lightweight stacks

The serverless tier, Upstash Vector, Supabase Vector, Turso, Xata, exists for teams who want vector search without an always-on database bill. You get an API, pay roughly per request or per stored vector, and integrate in an afternoon. For low-volume RAG, internal tools, and side projects this is exactly the right amount of database. It's also a sensible way to learn the shape of a RAG system before committing to heavier infrastructure. The limitations are the same ones that run through this whole list, just packaged smaller: these are vector primitives, not content systems. They store and search embeddings; they don't know what a product page, a release note, or a support article is. Every one of them assumes you've built the pipeline that reads from your real content source, chunks it, embeds it, and pushes it in, and that you'll keep that pipeline correct forever. The convenience is real. The architectural problem of two sources of truth is unchanged.

5. Sanity Context, retrieval that lives inside the content itself

Here's where the ranking flips. Sanity Context (previously Agent Context) isn't a vector database you point at your content, it's retrieval native to the Content Lake, where the content already lives. Hybrid search is a single GROQ query: `text::semanticSimilarity()` for meaning, a BM25 `match()` for exact terms, blended with `score()` and `boost()` to tune relevance, no second system to assemble. Because dataset embeddings are tied to the content, edits propagate within minutes; there's no separate pipeline to keep in sync and no drift to debug. Knowledge Bases turn datasets, websites, PDFs, and support databases into agent-readable documents on that same retrieval path, and your agents connect through the Sanity Context MCP endpoint. Editors govern what the agent retrieves and how it's instructed in Studio, staging changes with Content Releases the way they stage the website. Agent Actions handle generate, transform, and translate workflows with full schema awareness. One source of truth, governed by the people who own the content.