Resources · n8n integration

n8n Simple Vector Store nodeConfigure Simple Vector Store in n8n.

Everything this node stores lives in n8n's own memory, and nowhere else. The n8n Simple Vector Store node ships with 2 parameters, an operation mode with 4 choices and a memory key. It is built for people testing a retrieval setup before picking a real database.

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Simple Vector Store node actually do?

It keeps embeddings in n8n's in-app memory. Embeddings are numerical representations of text, stored as vectors, which let an AI find passages that mean roughly the same thing rather than passages that share the same words. Instead of standing up a vector database, you pick a memory key, insert documents under it, and query it from the same instance. n8n recommends the node for development use.

The node description says it plainly: the easiest way to experiment with vector stores, without external setup. That framing decides almost every question you will have about it. There is no account, no host, no index to provision. You drop the node in, choose insert, and the documents are searchable a few seconds later.

A first scenario: a support knowledge base you want to query from a chat workflow. One branch reads the source documents, splits them, and runs the node in Insert Documents mode under a memory key. A second branch runs the same node in Get Many mode with a Prompt and a Limit, and hands the ranked passages to whatever comes next. A second scenario: an agent that needs to look things up on its own. The Retrieve Documents (As Tool for AI Agent) mode turns the store into a tool an AI Agent can call, with a Name and a Description that tell the model when to reach for it. A third scenario: a question and answer flow, where the Vector Store Retriever node reads from this store and feeds the Question and Answer Chain.

When to prefer something else is the honest part. This node stores data in memory only. All data is lost when n8n restarts, and it may be purged under low-memory conditions. Memory keys are also global rather than scoped to a workflow, so anyone on the instance can add a Simple Vector Store node, select the key, and read what is in it. Sensitive material does not belong here. For anything that has to survive a restart or stay private to one team, the prototype graduates to a persistent store.

The documents themselves usually come from elsewhere in the workflow: rows pulled from Google Sheets, threads read from Gmail, messages archived from Slack. The model provider on the other side, OpenAI or Anthropic, bills its own API calls under its own terms, and n8n adds nothing to that.

Memory management runs on its own. Old stores get cleaned up as memory pressure rises, and stores that have not been accessed for a configurable stretch are removed. Two environment variables control it, N8N_VECTOR_STORE_MAX_MEMORY and N8N_VECTOR_STORE_TTL_HOURS, both set to -1 by default on self-hosted instances, which disables limits and time-based cleanup entirely.

Parameters

Which parameters does the node expose?

The Simple Vector Store node has 2 parameters. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Operation Mode

mode

What you see in n8n

Notes & use cases

This single selector decides what the node does on each incoming item, and every other field appears or disappears based on it.

Key parameters

  • Insert Documents (insert): writes documents into the store, with Clear Store to wipe the key first.
  • Get Many (load): ranks documents against a Prompt, capped by Limit, with Include Metadata and Rerank Results.
  • Retrieve Documents (As Vector Store for Chain/Tool) (retrieve): exposes the store to another AI node.
  • Retrieve Documents (As Tool for AI Agent) (retrieve-as-tool): needs a Name and a Description.
Use cases
one node in insert to build the index, a second in load to query it.
02

Memory Key

memoryKey

What you see in n8n

Notes & use cases

The key names the slot where the vector memory sits in the workflow data, and n8n prefixes it with the workflow ID so two projects do not collide.

Key parameters

  • Memory Key: select an existing key or type a new one, often something readable like company_knowledge_base, or an expression such as {{ $json.tenant }} when one workflow serves several datasets.
Use cases
the insert branch and the query branch must name the same key, otherwise the search runs against an empty store and returns nothing. Worth checking first when results come back blank.
Need help

Need help automating Simple Vector Store with n8n?

A person reads every message.

FAQ

Questions people ask before building with it

01Is the Simple Vector Store node included in n8n?
Yes. It belongs to the n8n AI package, shipped with n8n, so there is nothing to install and nothing extra to pay on the n8n side. It behaves the same on n8n Cloud and on a self-hosted instance, whether you run it with Docker or npm under the Community Edition and its Sustainable Use licence. A workflow built on one runs on the other. What can cost money sits elsewhere: the model provider you call to produce the embeddings, OpenAI, Anthropic, Google or Mistral, bills its own API calls under its own terms. n8n adds nothing on top of that.
02What credentials do you need to use it?
None. There is no credential to create and no Authentication selector on this node, which is unusual enough to be worth saying out loud. You add the node, pick a mode, name a memory key, and it runs. The account you do need lives on the model side: producing embeddings means calling a provider, and that provider's key is configured on its own node, not here. So the setup work is a single credential elsewhere in the workflow rather than anything on the Simple Vector Store node itself. That is part of why it is the fastest way to get a retrieval prototype running.
03What are the limits of the n8n Simple Vector Store node?
The big one is persistence, and n8n is explicit about it: this node stores data in memory only, all data is lost when n8n restarts, and it can be purged in low-memory conditions. n8n recommends it for development use. The second limit is access. Memory keys are global rather than scoped to a workflow, so any user on the instance can add the node, select the key and read the contents, whatever access controls the original workflow has. Do not ingest sensitive information with it. The node is at version 1 and exposes 2 parameters, so anything beyond mode and key is handled by neighbouring nodes.
04When should you connect it to an AI Agent instead of using it as a regular node?
It depends on who decides when to search. As a regular node in the connection flow, you control the moment: insert on one branch, query on another, no agent involved. Connect it to the tool connector of an AI Agent instead when the model should decide for itself whether a lookup is useful, which is the point of the Retrieve Documents (As Tool for AI Agent) mode and its Name and Description fields. Two other patterns exist: the Vector Store Retriever node feeding a Question and Answer Chain, and the Vector Store Question Answer Tool, which summarizes what it finds rather than returning raw passages.
05n8n or Make for a vector store workflow?
The deciding factor is usually hosting. n8n runs on your own server with Docker or npm, or on n8n Cloud, and the workflow is identical either way. Make is hosted only, with no self-hosting option, and bills per operation. For a store that holds document content, keeping the data on infrastructure you control matters more than usual, and an in-memory store on your own instance never leaves it. The cost model differs too: per-operation billing gets expensive on loops that insert many documents. Visual logic is a matter of taste, both are readable once you know them.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.