n8n Vector Store: pgvector vs Qdrant vs Pinecone

Nobody searching this wants a benchmark chart. They want permission to stop deliberating. So:

Already self-hosting n8n? pgvector. The Postgres is running, the backup job exists, and adding a vector column is a smaller change than adding a service. This is where I start every client build, including the one behind the Supabase lead database I wrote up earlier this year.

Filtering is most of the query?Qdrant. If every search is “similar to this, but only for account 42, in Spanish, from the last 90 days,” you want a database that was built around payload filtering rather than one that bolted it on.

Nobody on the team wants to run a database? Pinecone. You pay a real premium per query at scale, and in exchange you never think about an index again. For a small team shipping a client project on a deadline, that trade is often correct.

Prototyping today, deciding later?The Simple Vector Store, in memory, and don't pretend otherwise. It empties on restart. That's fine for the two hours you spend proving the retrieval idea works at all.

Every vector store node in n8n has the same set of operation modes: Get Many, Insert Documents, Retrieve Documents (As Vector Store for Chain/Tool), and Retrieve Documents (As Tool for AI Agent). Pinecone adds Update Documents.

Here's the part that changes architectures. In the PGVector node and the Qdrant node, Metadata Filter is listed as an option of Get Many. Not of the tool modes. Same for Pinecone. Switch the node to Retrieve Documents (As Tool for AI Agent) and your configuration surface is a name, a description, a collection, and a limit.

Which means: an agent using a native vector tool searches your entire collection on every call.It cannot scope itself to one tenant, one customer, one project. If you're building anything multi-tenant, that's not a nice-to-have missing, it's the whole security model missing.

Read that third row again, because it's the only row that should move your decision. Pinecone's Namespace option is available in all modes. That is a genuine functional advantage inside n8n specifically, and it has nothing to do with recall or p99 latency.

1. Isolate instead of filter.One namespace per tenant on Pinecone, one collection per tenant on Qdrant, one collection on pgvector. The agent's tool points at a name resolved from the execution context, so there is physically nothing else to retrieve. Cleanest option, and it fails safe. The cost is that cross-tenant queries become impossible and thousands of tenants become thousands of collections.

2. Wrap Get Many in a sub-workflow tool. Build a second workflow that takes a query plus filter values, runs the node in Get Many mode with Metadata Filter populated from those inputs, and returns chunks. Attach it as a Call n8n Sub-Workflow Tool. Now the model passes filter arguments per call — which is exactly what the native tool mode won't let it do. This is what I reach for most, and it's the same pattern I use for tools versus sub-workflows generally.

3. Retrieve before the agent runs.If the scope is known from the trigger — a support ticket for account 42 — don't make the agent decide. Run Get Many first, filtered, and inject the chunks into the system prompt. Fewer moving parts, one fewer model round trip, and no chance the agent forgets to search.

Self-hosted n8n already depends on Postgres. Turning on the vector extension gives you a vector store with no new container, no new credential, no new backup target, and no new thing to page you at 2am. That is worth more than most people weigh it at.

With an HNSW index, similarity queries over single-digit-million-row tables land in the tens of milliseconds. Put that in context: your agent's model call takes two to six seconds. Shaving 30 ms off a 4-second turn is not a project. I've never once traced a slow n8n agent back to Postgres — it's always the model, or a tool doing a synchronous HTTP call nobody instrumented, which is the argument for tracing agents properly before optimizing anything.

The real pgvector failure mode isn't speed, it's contention. Vector search is memory-hungry, and if it shares a box with your application queries and n8n's own execution tables, a heavy re-index will absolutely make your workflows feel slow. Same reasoning as picking a memory backend in Postgres vs Redis for agent memory: it's not which is faster, it's what else is on the machine.

Qdrant earns it when filtering dominates and you want the vector workload off your application database. It runs as one container, holds low-millisecond latencies at high recall, and its filtering is a first-class part of the query rather than a WHERE clause the planner has to reconcile with an approximate index. The n8n node also lets you pass a Collection Config JSON on insert, so you control how the collection is created instead of accepting a default.

Pineconeearns it two ways. The obvious one is that there's nothing to operate. The n8n-specific one is namespaces in every mode, plus an Update Documents mode the other two nodes don't have — if your corpus changes constantly and you need to correct a single chunk without a full re-ingest, that's a real capability difference, not a marketing one.

What Pinecone costs you is predictability at volume. Self-hosting means your ceiling is the box; serverless means your bill tracks your traffic. Neither is wrong. Just know which one you signed up for, and price it at the query volume you expect in a year — the same math I walk through in n8n Cloud vs self-hosted.

Most “which vector database” questions are really “my RAG gives bad answers” questions wearing a costume. Swapping stores almost never fixes that, because all three run approximate nearest neighbour over the same embeddings you gave them. Garbage chunks in, confidently wrong citations out.

In order, the things that actually moved retrieval quality on my builds: chunk size and overlap in the text splitter, the retrieval limit (the default is usually too small — pull ten and rerank down to four), a reranker node, and the tool description, because the agent decides whether to search at all based on that sentence. A vague description means the model answers from memory and never calls your beautifully tuned store.

None of that is measurable by vibes. Keep a fixed set of twenty real questions with known-good answers, run them after every change, and count. That's the whole idea behind evaluating n8n agents instead of eyeballing them.