n8n Vector Store for RAG Production: pgvector vs. Qdrant vs. Pinecone

By Roman Rodomansky·Published 8 Oct 2026

A comparison of pgvector, Qdrant and Pinecone as the n8n vector store for RAG production, covering node support, scaling, filtering and cost.

• n8n
• Vector databases
• Tool comparison
• Production readiness
• Comparison

Checked against the cited sources on 8 Oct 2026.

What Changes When an n8n RAG Workflow Moves from Prototype to Production

Picking the right n8n vector store for RAG production work means deciding how your workflow will store and retrieve embeddings once real users, not just a workshop demo, depend on the answer. A prototype can get away with an in-memory index that disappears on restart. Production cannot: the index has to survive restarts, hold the whole knowledge base, and keep answering queries while new documents are added.

This echoes a limitation stated on n8n Balloon Challenges own Ask Your Google Drive challenge, where the Simple Vector Store node is described as suitable only for the workshop demo, not for production use. We think skipping that warning is one of the easiest ways an n8n RAG workflow quietly breaks once real traffic arrives.

n8n Vector Store for RAG Production: Node Support in pgvector, Qdrant and Pinecone

Inside n8n, the three stores are not identical building blocks. According to n8n's own documentation, the PGVector Vector Store node lets a workflow insert documents into a Postgres vector table, fetch documents from it, or retrieve documents through it, and the same node can act as a regular node, a tool for an AI agent, or the retriever behind a chain. n8n's documentation describes the Qdrant Vector Store node the same way: insert, get, and retrieve against a Qdrant collection, usable as a regular node, an agent tool, or a retriever.

• Regular node: insert or fetch documents directly in a workflow step
• AI Agent tool: let an agent call the vector store as one of its tools
• Retriever: supply matched documents automatically to a chain or agent

Pinecone's node documentation adds one mode the other two don't document: updating an existing vector record by its ID, rather than only inserting or retrieving. If your production design depends on in-place updates to embeddings, check each node's documentation before you commit, since the three nodes don't expose identical modes.

Sources: PGVector Vector Store | Nodes | n8n Docs, Qdrant Vector Store | Nodes | n8n Docs, Pinecone Vector Store | Nodes | n8n Docs

Scaling and Index Design: Operational Overhead for pgvector and Qdrant

Once a single Postgres instance isn't enough, pgvector's own documentation points teams toward scaling horizontally with read replicas or toward sharding tools such as Citus or PgDog, rather than toward a built-in distributed mode. That's a real engineering project, not a configuration flag.

Qdrant's own production documentation is organized around similar groundwork: planning multitenancy, bulk uploads, and which memory tier a collection lives in as it grows. Its production checklist also states that a self-hosted, open-source Qdrant instance has no authentication by default, so setting an API key is the minimum step before any production deployment, and it flags storage and hardware sizing decisions as hard to reverse once a deployment is already live.

• Set an API key before exposing a self-hosted Qdrant instance to any network
• Plan multitenancy and bulk-upload paths before collections grow
• Size RAM, disk type and memory tier before go-live, since these are hard to change later

Sources: GitHub - pgvector/pgvector: Open-source vector similarity search for Postgres · GitHub, Production & Operations - Qdrant, Production Checklist - Qdrant

Pinecone's Filtering Tradeoffs and What Each Vendor's Benchmarks Claim

Pinecone frames its filtering architecture around a specific tradeoff: in a 2023 explainer, Pinecone describes pre-filtering before a vector search as accurate but slow, because it requires an exhaustive brute-force scan, which is part of why Pinecone built metadata filtering directly into its serverless engine. In Pinecone's own 2025 ICML research paper on that serverless design, Pinecone's engineers report a mean Recall@10 of 0.989 on the YFCC filtered-ANN benchmark, holding up across a wide range of filter selectivity.

Qdrant makes a parallel first-party claim: according to Qdrant's own benchmark updated January and June 2024, Qdrant reports the highest requests-per-second and lowest latency in almost every scenario it tested, including a 4x RPS gain on one dataset. Qdrant's own benchmark page is candid that its authors know their product best and may not have tuned competing engines as carefully.

Our take is that a vendor-run benchmark is useful for narrowing a shortlist, not for settling it: treat these numbers as a starting point, then verify metadata filtering and recall against your own documents before you decide.

Sources: Vector Search Benchmarks - Qdrant, https://www.pinecone.io/research/ICML_2025.pdf, The Missing WHERE Clause in Vector Search

Cost and Pricing Model Differences

Pricing mechanics differ as much as the technology does. Pinecone's documentation sets fixed operation limits that don't change by plan, such as request-rate ceilings and a maximum of 1,000 records (up to 2 MB) per upsert batch with a 10,000 cap on query top_k, limits an n8n ingestion workflow has to be designed around from the start. Pinecone's own cost documentation describes its serverless billing as fully usage-based, charging only for stored data and operations run, with an idle index costing nothing.

Qdrant Cloud bills differently: resource-based pricing tied to vCPU, RAM and disk, so a bigger cluster costs more, charged monthly in arrears for the previous month's usage. Self-managed open-source Qdrant carries no Qdrant-billed cost at all, but then your own infrastructure bill replaces it.

Sources: Pinecone Database limits overview - Pinecone Docs, Operation limits - Pinecone Docs, Understanding Pinecone cost - Pinecone Docs, Pricing for Cloud and Vector Database Solutions Qdrant, Billing & Payments - Qdrant

Decision Guide: Matching the Store to Your Team's Constraints

There's no single best n8n vector store for RAG production that fits every team; the right pick follows your constraints more than any one benchmark number.

The recommendations below summarize how the documented tradeoffs line up against a few common team situations.

• Start with pgvector if you already run Postgres and filtering needs are modest, but follow pgvector's own guidance on indexing and sharding before you hit limits
• Choose Qdrant if you need strict filtering, hybrid search or large-scale retrieval and are willing to self-host, after working through Qdrant's own production checklist
• Choose Pinecone if minimizing operations matters most and usage-based billing is acceptable, designing ingestion around its documented batch and top_k limits
• Confirm in n8n's own node documentation that the workflow pattern you need is supported by that specific node before committing

We're generally in favor of starting an n8n RAG workflow on pgvector when the team is already running Postgres, since it avoids standing up a brand-new system before anyone has proven it's actually needed; move to Qdrant or Pinecone once a concrete scaling or filtering limit, not a hunch, forces the question.

Whichever store you choose, standardizing this n8n vector store for RAG production decision across a team, rather than letting each workflow choose ad hoc, is what keeps a future audit simple.

Sources: PGVector Vector Store | Nodes | n8n Docs, Qdrant Vector Store | Nodes | n8n Docs, Pinecone Vector Store | Nodes | n8n Docs, GitHub - pgvector/pgvector: Open-source vector similarity search for Postgres · GitHub, Production & Operations - Qdrant, Production Checklist - Qdrant, Pinecone Database limits overview - Pinecone Docs, Operation limits - Pinecone Docs, Understanding Pinecone cost - Pinecone Docs, Pricing for Cloud and Vector Database Solutions Qdrant, Billing & Payments - Qdrant