RAG

The RAG Database: Retrieval Built In

Retrieval-augmented generation is only as good as its retrieval layer. Montycat is a self-hosted database that stores your documents and their vector embeddings together and returns the most relevant passages by meaning — the retrieval half of RAG, without bolting on a separate vector store. The retrieval layer is part of the database, not a fragile service beside it.

Read the docs

What is a RAG database?

Retrieval-augmented generation grounds an LLM in your own data: instead of relying only on what the model memorized during training, you retrieve relevant passages from your content and pass them to the model as context. This is how you get accurate, source-backed answers over private or up-to-date data — and how you cut hallucinations.

A RAG database is the system that does the retrieval half: it stores your content as vector embeddings and finds the passages closest in meaning to a query. Most stacks run a dedicated vector database next to a primary store and keep them in sync. Montycat collapses that into one engine — the records and their vectors live together.

The RAG retrieval pipeline

Every RAG system moves through the same stages. Montycat owns the storage and retrieval stages so you do not assemble them from separate services:

  • Ingest — write documents to a keyspace as you would any record.
  • Embed — Montycat vectorizes each write automatically, on-device, in the background.
  • Index — vectors go into an approximate nearest-neighbor (HNSW) graph for sub-linear search.
  • Retrieve — embed the user question and run kNN to get the top-k most relevant passages, with scores.
  • Generate — pass those passages to your LLM as grounding context.

How RAG works on Montycat

Write your documents to a keyspace; Montycat embeds and indexes them in the background, so your ingest path never blocks on embedding. At query time, embed the user question and run a kNN search to get the top-k passages by cosine similarity, optionally filtered by a score floor so low-confidence chunks never reach the model.

You can retrieve full values ({__key__, __score__, __value__}) to feed the model directly, or lightweight keys ({__key__, __score__}) to page results before fetching. Either way, the passages come back ranked by meaning, not keyword overlap.

Keeping retrieval fresh

RAG quality decays when your index drifts from your source data. Because records and vectors share the same engine in Montycat, updating or deleting a document updates its retrievability immediately — there is no nightly re-index job and no window where the vector store disagrees with the source of truth. New writes become searchable as the background worker embeds them.

Why one engine beats two

A separate vector database means a sync job, two sources of truth, a second service to operate and secure, and a per-query retrieval bill. Keeping embeddings beside the data they describe removes the drift and the extra infrastructure — and keeps everything on your own hardware, with on-device embeddings and no external API in the loop.

What teams build with it

The same retrieval layer powers a wide range of RAG applications:

  • Question-answering over internal docs, wikis, and knowledge bases.
  • Support assistants grounded in product documentation and past tickets.
  • Code and API assistants that retrieve relevant snippets and references.
  • Research and analysis tools that cite passages from a private corpus.

Retrieve context for RAG (Node.js / TypeScript)

// semantic search is on by default in the montycat-semantic edition
const context = await docs.semanticSearchGetValues({
  query: userQuestion,
  limitOutput: { start: 0, stop: 5 },
});
// pass the ranked passages to your LLM as grounding context

FAQ

Can Montycat replace a dedicated vector database in a RAG stack?

Yes. Montycat stores your data and its embeddings and serves kNN retrieval itself, so you do not need a separate vector database next to your primary store.

Do embeddings require an external API?

No. Montycat embeds on-device with a built-in engine — no API keys, no per-query bill, no data egress.

How do I keep retrieval in sync with my data?

You do not have to. Records and their vectors live in the same engine, so writes update retrievability automatically — there is no separate index to reconcile.

Does Montycat do the generation step too?

No — Montycat is the retrieval layer. You bring your own LLM (local or hosted) and feed it the passages Montycat returns. That keeps you free to choose any model.

How do I control retrieval quality?

Tune the number of results (top-k) and apply a minimum cosine-similarity score to drop weak matches, so only high-confidence passages are passed to the model as context.

Explore