Which vector database should I use with n8n?

For almost every agency and SMB workload, use pgvector on the Postgres you already run for n8n. Under roughly 5 million vectors it is fast enough, costs nothing extra, and keeps your chunks and their source records in the same database so you can join them in one query. Move to Qdrant when you pass a few million vectors or need heavy metadata filtering, and consider Pinecone only when you want someone else to own scaling and latency at tens of millions of vectors. The vector store is rarely the thing that makes a RAG workflow good or bad.

Is pgvector fast enough for production RAG?

Yes, for the sizes most businesses actually have. A knowledge base of company docs, past tickets, and product data usually lands between 20,000 and 500,000 chunks, which pgvector handles in single- or low-double-digit milliseconds with an HNSW index. We run client RAG agents on pgvector where retrieval is consistently under 40ms and the model call takes 30 to 60 times longer. Latency complaints in n8n RAG workflows almost always trace back to the LLM or a slow tool call, not the vector search.

What does a vector database cost in 2026?

At around 10 million vectors, self-hosted Qdrant runs roughly $65 per month on a modest VPS and Pinecone lands near $70 on managed serverless pricing. pgvector on a Postgres instance you already pay for adds nothing. The gap only becomes dramatic at very large scale, where managed pricing can pass $700 per month while a self-hosted store stays under $100. Below 100,000 vectors, paying anything at all for a dedicated vector database is hard to justify.

Can I switch vector databases in n8n later?

Yes, and that is the main reason not to overthink the choice. n8n's vector store nodes share the same shape, so swapping pgvector for Qdrant usually means replacing one node and re-running your ingestion workflow to repopulate the new store. The expensive part is never the node, it is re-embedding the corpus, which costs real money and time on a large knowledge base. Keep your ingestion workflow clean and repeatable and a migration is an afternoon, not a project.

Do I need a vector database at all for my n8n AI agent?

Often not. If the knowledge the agent needs fits in a prompt, or lives in a structured system you can query directly through an API or SQL node, skip retrieval entirely and hand the agent a tool. Vector search earns its place when you have a large volume of unstructured text with no reliable keys, like support tickets, transcripts, or PDFs. We kill about a third of the RAG requests we get in the first scoping call because a plain database query answers the question better.

n8n Vector Database: pgvector vs Qdrant vs Pinecone

A client came to us in June convinced they needed Pinecone. They had watched a tutorial, priced out a starter plan, and budgeted for it. Then we counted their actual corpus: 14,000 support tickets and about 90 PDFs. Roughly 62,000 chunks after splitting. We put it in the Postgres instance already running underneath their n8n and it has never once been the slow part of the workflow.

Here's the short version: for n8n RAG workflows, use pgvector on the Postgres you already run until you pass a few million vectors. Move to self-hosted Qdrant when metadata filtering or corpus size starts to hurt, and reach for Pinecone only when you genuinely want to outsource scaling at tens of millions of vectors. Below 100,000 chunks, a dedicated vector database is a line item you cannot defend.

That's the answer. The rest of this is why, plus the parts of an n8n RAG build that actually decide whether it works.

What n8n Actually Supports

n8n ships native vector store nodes for Pinecone, Qdrant, Supabase, PGVector on plain Postgres, Weaviate, Milvus, and an in-memory store for testing. The official RAG documentation covers the wiring, and it's genuinely straightforward — the nodes share a common interface, so the workflow graph looks nearly identical no matter which store sits underneath.

That interchangeability is the most important fact in this entire decision. You are not making a one-way door choice. Swapping stores means replacing one node and re-running ingestion. The only expensive part is re-embedding, and that's a cost you pay in tokens and patience, not in rewritten workflows.

So stop agonizing. Pick the cheapest thing that clears your bar, ship it, and revisit when something actually breaks.

One caveat worth naming: the in-memory vector store is a trap in the same way Simple Memory is. It works beautifully in a canvas test and evaporates on restart. We treat it the same way we treat Simple Memory in n8n AI agents — fine for a five-minute demo, never in something a client depends on.

pgvector: The Default You Should Argue Against, Not For

pgvector adds vector similarity search to ordinary Postgres tables. If you self-host n8n, you already have a Postgres instance running. Enabling the extension is one SQL statement, and the n8n PGVector Store node will create the table for you on first insert.

What you get for free:

Zero additional infrastructure. No new container, no new backup job, no new thing to monitor at 2am. If you've read our take on self-hosted vs cloud n8n, you know we're allergic to adding services that need their own operational story.
Joins. Your chunks live in the same database as your customers, orders, and tickets. You can filter a vector search by customer_id in SQL, in one query, without shipping IDs between two systems and hoping they stay in sync. This is a bigger deal in practice than any benchmark number.
One backup covers everything. Your embeddings are in the same dump as your relational data. Point-in-time restore restores both, consistently.
Real performance at real sizes. With an HNSW index, a 60,000-chunk table returns in single-digit milliseconds on modest hardware. Our production client RAG agents sit consistently under 40ms on retrieval while the model call takes 1.5 to 3 seconds. The vector search is a rounding error.

Where it stops being the right answer:

Past roughly 5 to 10 million vectors, index build times get long and memory pressure on the Postgres box becomes a real conversation. Heavy metadata filtering combined with high query concurrency is also not pgvector's strength — the filtering happens in a way that can degrade recall in ways a purpose-built engine handles more gracefully.

If you are in that territory, you know it. If you're not sure whether you're in that territory, you are not.

Qdrant: The Right Second Step

When pgvector genuinely stops fitting, Qdrant is where we go. It's open source, self-hostable, written in Rust, and its filtering story is meaningfully better — payload-based filters are first-class rather than bolted on, which matters when every query needs to be scoped to a tenant, a date range, and a document type at once.

Cost-wise, at around 10 million vectors, self-hosted Qdrant lands near $65 per month on a modest VPS. That's real money for real capability, and it stays flat as you grow because you own the box.

The tradeoff is honest: you now operate a second stateful service. That means backups, upgrades, disk monitoring, and a new failure mode in your on-call story. For a two-person agency running twelve client workflows, that's a genuine cost that never shows up on an invoice. Budget for it or don't make the move.

We also use Qdrant when a client's data can't share a database with anything else for compliance reasons. Physical separation is sometimes a requirement, not a preference.

Pinecone: When You're Buying Someone Else's On-Call Rotation

Pinecone is a managed serverless vector database, and it's good. It's also priced like a managed service, landing around $70 per month at 10 million vectors and climbing past $700 at 100 million, where a self-hosted store stays under $100.

That premium buys exactly one thing: you never think about it. No index tuning, no disk, no upgrade window. For a team that's scaling fast and would rather spend engineering hours on the product, that's a completely defensible trade.

What we push back on is Pinecone at 50,000 vectors, which is where most people first reach for it because it's the name they've heard. At that size you're paying a managed-service premium to solve a scaling problem you will not have for years, and you're adding a network hop and an API dependency to a query that Postgres would have answered locally in 4ms.

Rule of thumb we use with clients: if you cannot articulate the specific limit of pgvector you expect to hit, you're buying comfort, not capability. Sometimes comfort is worth $70. Just name it honestly.

Supabase Sits in a Useful Middle

Supabase's vector store is pgvector with a managed Postgres, an API layer, and auth around it. If a client's stack is already on Supabase — and a lot of the full-stack builds we ship are — using its vector store is the obvious call. Same engine, same join advantages, someone else running the database.

It's not a different technology decision. It's the same pgvector decision with the ops outsourced.

The Part That Actually Decides Whether Your RAG Works

Here's what nobody wants to hear after spending a week comparing vector databases: the store is maybe the fifth most important variable in retrieval quality. We have never once fixed a bad RAG agent by changing the vector database. We have fixed plenty by changing these:

Chunking. Splitting on a fixed character count mid-sentence destroys meaning. Split on semantic boundaries — headings, paragraphs, ticket messages — at roughly 500 to 1000 tokens with overlap. This single change has moved answer quality more than any other lever we've pulled.
Metadata. Store source URL, title, date, and document type with every chunk. Without it you cannot filter, you cannot cite, and you cannot debug why the agent surfaced a two-year-old policy doc.
What you embed. Embedding a raw HTML dump, nav menus and cookie banners included, poisons your index with noise that matches everything and means nothing. Clean before you embed.
Retrieval as a tool, not a gate. Attach the vector store as a tool on the AI Agent node rather than forcing every message through retrieval. "What's your refund policy" needs the knowledge base. "Thanks, that helps" does not, and searching anyway wastes latency and tokens.
Evaluation. Keep 20 to 30 real questions with known-correct sources and re-run them after every change. This is the same discipline we describe in testing n8n AI agents before production, and it's the difference between knowing your agent got better and hoping it did.

One more, because it bites people: retrieved content is untrusted input. If your knowledge base ingests customer-submitted tickets or scraped pages, a malicious chunk can carry instructions the model will happily follow. We covered the mechanics in prompt injection in n8n AI agents, and RAG is exactly the surface where it shows up.

How We'd Decide in 90 Seconds

Under 100,000 chunks: pgvector on your existing Postgres. No debate. If you're already tracking small structured state in n8n, our note on Data Tables vs an external database covers where that line sits.
100,000 to 5 million chunks: still pgvector, but add an HNSW index and watch your query times.
5 million+ chunks, or filter-heavy multi-tenant queries: self-hosted Qdrant, and accept that you now run a second service.
Tens of millions of vectors, or a team that shouldn't be doing database ops: Pinecone, deliberately, with the cost named out loud.
Already on Supabase: Supabase vector store. Stop reading.

The wrong move isn't picking the wrong database. It's spending three weeks picking one while your ingestion workflow still chunks at 2000 characters on a hard split and nobody's written down a single test question.

Get a Free Automation Audit

If you're building RAG into an n8n workflow and you're not sure whether your chunking, your retrieval, or your model is the problem, we'll look at it. Get a free automation audit — we go through your workflows, tell you which parts of the retrieval pipeline are actually costing you quality, and hand you the list. No pitch attached.

We've built over 200 n8n workflows. The number of times the vector database was the bottleneck: two.