Skip to main content
You don’t always need an entity graph and typed extractions. Sometimes you just want “given a query, return the most relevant chunks of this user’s past conversations.” Synap does this too: its ContextResponse is queryable like a vector store, with the bonus that retrieval is automatically scoped to the user.
Why this works without your own vector DB
  • Synap embeds every ingested document at ingest time and stores the vectors in its vector engine.
  • mode="accurate" combines vector similarity with graph traversal, so a query about “the project Bob is leading” pulls memories about Bob even if Bob isn’t named in the query verbatim.
  • All retrievals are scoped: you cannot accidentally fetch another user’s data.
When this isn’t enough If you have non-conversational sources (PDFs, knowledge base articles, web pages) that you want to retrieve over, you have two options:
  1. Ingest them into Synap with document_type="document" at the CUSTOMER or CLIENT scope. They become part of the same retrieval surface as user history.
  2. Keep a separate vector DB for the document corpus and merge results at the application layer. Use Synap for memory only.
Option 1 is simpler and gets you scope-aware retrieval for free. Option 2 makes sense if you already have a doc corpus indexed and don’t want to re-ingest. Comparing to a raw vector DB If “I just want a vector DB” is genuinely all you want, pgvector is cheaper. If you’re going to end up building scope isolation, multi-source merge, and reranking on top of pgvector, you’re rebuilding Synap.

Going further