Do I need a vector database to build RAG?

Only if retrieval quality is your product. A vector database stores and searches embeddings; it does not give you layout-aware parsing, chunking, reranking, claim-to-source mapping, page-level evidence or refusal behaviour. If you want cited answers rather than a retrieval platform, a hosted retrieval API is less to own.

What is an alternative to Pinecone, Weaviate or Qdrant?

A hosted retrieval service such as Uthereal Cortex, called through @uthereal-sdk/cortex. You send a question and get ranked evidence or a cited answer back. There is no index to size, no embedding model to version and no reranker to tune.

Is pgvector enough for production RAG?

pgvector is a good store. Production quality comes from everything around it: document parsing, chunk boundaries, hybrid search, reranking, evaluation and citation rendering. Teams usually underestimate that surrounding work by months.

What do I give up by not running my own vector store?

Direct control over the index and embedding model. What you keep is your content, your data residency and your exit: sources stay yours, processing is EU or Swiss resident with zero retention, and no customer data trains anyone's model.

Can I still get raw ranked results?

Yes. The rag endpoint returns ranked JSON passages with identifiers and metadata, so you can feed your own model or agent without using the generated answer at all.

Do you actually need a vector database?

Every RAG tutorial starts with an index. Most products do not need one. What they need is an answer their users can verify, and a vector database is only the first ten percent of that.

Last updated 18 September 2026 · SDK v1.1.0 · changelog

Short answer: run a vector database when retrieval itself is your product and you have a team to tune it. Otherwise use a hosted retrieval API. @uthereal-sdk/cortex replaces the index, the embedding pipeline, the reranker and the citation layer with one install, and returns claim-level citations with page-level PDF evidence.

Create your agent Read the SDK guide

What running your own index means you own

Document parsing that survives tables, headings, footnotes and columns
Chunking strategy, and the re-indexing that follows every change to it
Embedding model choice, versioning and the cost of re-embedding the corpus
Hybrid search and reranking, with an evaluation set to prove either helps
Claim-to-source mapping and a citation UI, including PDF page rendering
Refusal behaviour, so missing evidence produces silence rather than fiction
Index operations: scaling, backups, residency, access control, cost drift

Three ways to get retrieval

Vector database (pgvector, Pinecone, Weaviate, Qdrant): maximum control, you build everything above the index
Framework (LangChain, LlamaIndex): scaffolding for the pipeline, you still operate the index and the quality loop
Hosted retrieval API (Uthereal Cortex): one install, cited answers, no retrieval infrastructure to operate

The right answer depends on whether retrieval quality is a differentiator for you or a prerequisite. For knowledge products in publishing, professional services, finance and government, it is almost always a prerequisite.

What the swap looks like

Replacing the retrieval stack

// before: index, embed, search, rerank, assemble prompt, hope
// after:
import { createCortexHandler } from "@uthereal-sdk/cortex/server";

const handler = createCortexHandler({
  config: {
    baseUrl: process.env.CORTEX_API_BASE_URL!,
    assistantId: process.env.CORTEX_ASSISTANT_ID!,
    apiKey: process.env.CORTEX_SHARED_API_KEY!,
  },
  authenticate,
  store,
});

Retrieval-only is available too: cortex.rag({ query, max_results }) returns ranked JSON evidence for your own model.

Keeping control without keeping the index

EU or Swiss data residency, zero retention, no training on your content
Your sources remain yours and can be removed at any time
Model choice stays with you, so you are not locked to one provider
Ranked JSON output means you can always fall back to your own generation

Frequently asked questions

Do I need a vector database to build RAG?: Only if retrieval quality is your product. A vector database stores and searches embeddings; it does not give you layout-aware parsing, chunking, reranking, claim-to-source mapping, page-level evidence or refusal behaviour. If you want cited answers rather than a retrieval platform, a hosted retrieval API is less to own.
What is an alternative to Pinecone, Weaviate or Qdrant?: A hosted retrieval service such as Uthereal Cortex, called through @uthereal-sdk/cortex. You send a question and get ranked evidence or a cited answer back. There is no index to size, no embedding model to version and no reranker to tune.
Is pgvector enough for production RAG?: pgvector is a good store. Production quality comes from everything around it: document parsing, chunk boundaries, hybrid search, reranking, evaluation and citation rendering. Teams usually underestimate that surrounding work by months.
What do I give up by not running my own vector store?: Direct control over the index and embedding model. What you keep is your content, your data residency and your exit: sources stay yours, processing is EU or Swiss resident with zero retention, and no customer data trains anyone's model.
Can I still get raw ranked results?: Yes. The rag endpoint returns ranked JSON passages with identifiers and metadata, so you can feed your own model or agent without using the generated answer at all.

Build vs framework vs SDK

The full cost comparison.

Cortex vs LangChain

Framework or hosted retrieval.

Choosing a RAG API

Eight provenance criteria.

Supabase RAG

Cited answers without pgvector.