Vector Store Search vs Knowledge Base
When to use a managed Knowledge Base and when to query your own vector store directly with Vector Store Search and Writer nodes.
Dynamiq gives you two ways to put vector retrieval in a workflow: a Knowledge Base (managed RAG — Dynamiq runs the ingestion pipeline and storage) or the Vector Store Search and Vector Store Writer nodes (direct access to an index you operate yourself). This page is the decision guide.
The two paths
Knowledge Base is the managed path. You get an ingestion workflow (conversion → chunking → embedding → storage), data sources with sync (uploads, website crawling, OAuth integrations), Dynamiq-managed vector storage by default, a search endpoint on its own hostname, and the Knowledge Base Retriever node — shown as Knowledge Base Search on the canvas — which needs exactly one setting: which Knowledge Base to search. Query embedding automatically matches the ingestion embedder.
Vector Store Search is the direct path. The node queries an existing index in your own vector store — Weaviate, Pinecone, Milvus, pgvector, Elasticsearch, OpenSearch, Chroma, or Qdrant — using your Connection. You configure two child nodes yourself: a Text embedder (which must produce the same vector space as whatever wrote the index) and a Document retriever for your specific store. The matching Vector Store Writer node writes documents the same way, pairing a Document embedder with a store-specific Document writer — useful when your workflow also produces the documents it later searches.
Both retrieval nodes live under VECTOR STORES in the workflow palette, and both expose the same query-side controls: Max documents, Use hybrid search, metadata Filters, and a Description for agent use.
Comparison
| Knowledge Base | Vector Store Search / Writer | |
|---|---|---|
| Ingestion | Built in: converters, splitter, embedder, writer generated for you; customizable per node | Your responsibility — index data yourself, or build a flow with Vector Store Writer |
| Data sources & sync | Files, website crawling, Google Drive / Notion / SharePoint and more, with pause/resume and sync history | None — the node only reads/writes the index |
| Storage | Dynamiq-managed by default (your own store optional at creation) | Always your store, your Connection, your index name |
| Query embedding | Automatic — always the ingestion embedder | You pick the Text embedder; keeping it consistent with the index is on you |
| Item lifecycle | Items with statuses, ingestion traces, reprocess, delete-with-vectors | Not tracked — documents are whatever lives in your index |
| HTTP access | Dedicated hostname with upload + POST /v1/documents/search endpoints | None — query through a deployed workflow |
| Filters / hybrid search / top-k | Yes, on the retriever node | Yes, on the retriever node |
| Node to use | Knowledge Base Retriever (canvas title Knowledge Base Search) | Vector Store Retriever (canvas title Vector Store Search), Vector Store Writer |
Choose a Knowledge Base when…
- Your content starts as files, websites, or SaaS documents and someone has to convert, chunk, and embed it — that's exactly the pipeline a Knowledge Base generates and operates.
- You want syncing sources, item statuses, ingestion traces, and reprocessing without building any of it.
- You want a search endpoint over HTTP without deploying a workflow.
Choose vector store nodes when…
- The index already exists — populated by another team, an offline batch job, or a system outside Dynamiq — and you just need to query it.
- You need a store or index layout the Knowledge Base path doesn't manage for you, or you share one index across multiple applications.
- Your workflow writes and reads its own documents at run time, so the Vector Store Writer → Vector Store Search pair inside one workflow is the natural shape.
You can mix them: a Knowledge Base created with your own vector store connection keeps the managed ingestion pipeline while the vectors land in your infrastructure. And per-store retriever/writer nodes (Pinecone Retriever, Qdrant Writer, …) are available individually under VECTOR STORE RETRIEVERS and VECTOR STORE WRITERS when you want to wire them without the wrapper nodes — see the node reference.
Both, wired to an agent
Either node can be an agent tool. With a Knowledge Base, click Add knowledge on the Agent node — it attaches a Knowledge Base Retriever in one click (see Connect a Knowledge Base to Agents). With your own store, add Vector Store Retriever as a tool instead and configure its embedder and retriever:
- Select the Agent node and add the tool.
- Knowledge Base path: pick the Knowledge Base, set Max documents and filters, write the tool Description.
- Vector store path: pick a Text embedder (e.g. OpenAI Text Embedder) and a Document retriever (e.g. Pinecone Retriever) with your Connection and index, then set the same query controls and Description.
At run time the agent treats both identically: it writes a search query, calls the tool, and reasons over the returned chunks. The difference is everything upstream of the query.
Next steps
Connect a Knowledge Base to Agents
Attach a Knowledge Base Retriever tool to an Agent node and tune top-k, hybrid search, filters, and similarity threshold.
Build a RAG Pipeline
An end-to-end worked example: create a Knowledge Base, ingest files and a website, verify retrieval, attach it to an agent, deploy, and call it over HTTP.