Qdrant or pgvector for your n8n RAG: how to choose your vector database

When building a RAG pipeline in n8n, one decision comes very early and shapes everything downstream: where do the embeddings live? The two most common answers in the self-hosted ecosystem are pgvector, PostgreSQL's vector extension, and Qdrant, a dedicated vector search engine. Both have a native vector store node in n8n, both deploy with Docker next to your instance, and both do the job very well — but not with the same philosophy or the same operational consequences. This guide compares the two options on the criteria that actually matter for an n8n project, with an honest recommendation at the end.

Two vector database philosophies

pgvector: vector search inside the database you already run

pgvector is not a database: it's a PostgreSQL extension that adds a vector column type, distance operators, and approximate indexes (HNSW, IVFFlat). The entire value proposition lies in that integration:

• One less database to operate. If your stack already runs on Postgres or Supabase — which is true of many self-hosted n8n setups —, vector search bolts onto what exists, with no new service to deploy, monitor, and back up.
• SQL joins with your business data. Your vectorized chunks live in a Postgres table like any other: you can join them to your customers table, filter by tenant, cross-reference access rights, all in a single SQL query.
• Transactions. Inserting a document, its chunks, and its embeddings in one transaction, with a rollback if any step fails, is natural in SQL — a genuine comfort for a reliable ingestion pipeline.
• Existing tooling. Backups via pg_dump, replication, monitoring, role management: everything you already know how to do with Postgres applies to your vectors as-is.

The trade-off: vector search remains one feature among many in a general-purpose engine, with the index compromises detailed in our article on HNSW vs IVFFlat for pgvector.

Qdrant: a dedicated engine built to do one thing

Qdrant is a specialized vector database written in Rust, designed from the start for similarity search at scale. Its philosophy is the mirror image: instead of extending a general-purpose engine, optimize everything for a single use case.

• A clean, dedicated API (REST and gRPC), organized around collections of points, each carrying a vector and a freely structured metadata payload.
• Advanced payload filtering. This is Qdrant's signature: metadata filters (nested conditions, ranges, geo matching, must/should/must_not combinations) are integrated into the index traversal itself, rather than applied after the fact on results. For a multi-tenant or heavily filtered RAG, that's an architectural difference, not a convenience.
• Built-in quantization. Qdrant can compress vectors in memory (scalar, binary, or product quantization) to drastically shrink the RAM footprint of a large corpus, with re-scoring against original vectors to preserve quality.
• Independent sizing. Vector search becomes a standalone service you can scale, restart, or version without touching your business database.

The trade-off is symmetrical: one more service to deploy, monitor, and back up, and metadata that lives apart from your business data — any join with the rest of the system goes through your code or your workflows.

What n8n supports natively

Good news: the choice barely constrains how you build the workflow. n8n ships vector store nodes for both options, usable interchangeably in RAG chains:

• the Qdrant Vector Store node, which connects to a Qdrant instance (self-hosted or cloud);
• the Supabase Vector Store node and the PGVector Vector Store node, which sit on top of a pgvector table — the former through Supabase, the latter on any PostgreSQL with the extension enabled.

In both cases, the node works in insert mode for ingestion (receive split documents, call the embedding model, write the vectors) and in retrieval mode as a tool for an AI Agent or a question-answering chain. The rest of the pipeline — chunking documents, choosing an embedding model, optionally reranking results — is strictly identical whichever database you pick. Migrating from one to the other means swapping a node, recreating credentials, and re-ingesting the corpus.

The criteria that actually make the difference

Vector volume. This is the most structural criterion. Below a few hundred thousand vectors, both options are comfortable. Between a few hundred thousand and a few million, pgvector remains entirely viable with a properly tuned HNSW index and an instance sized accordingly. Beyond several million vectors, Qdrant's dedicated architecture — quantization, specialized memory management, sharding — starts to genuinely tip the scales.

Metadata filter complexity. If your searches boil down to "documents from this workspace" or "chunks of this type", both work fine (pgvector via a WHERE clause, Qdrant via its payload). If your RAG must combine many nested conditions on every query — tenant, permissions, time range, tags, source —, Qdrant's index-integrated filtering is designed for exactly that, whereas a highly selective SQL filter combined with an approximate index takes more care on the pgvector side.

Your existing stack. A team already on Postgres or Supabase has every reason to start with pgvector: credentials exist, connecting n8n to Supabase is well-trodden ground, and the learning curve is nearly zero. Introducing Qdrant means introducing a new component with its own learning curve — justifiable, but not free.

Self-hosting. A near-perfect tie: both deploy as a Docker container next to n8n, on the same docker-compose.yml as in our n8n Docker installation guide. Qdrant needs a persistent volume for its collections; pgvector lives in the Postgres volume you already have (or in a dedicated Postgres container if you prefer to isolate the vector database from n8n's internal one).

Backups. An often-overlooked point that leans clearly toward pgvector: if you already follow a PostgreSQL backup routine for your self-hosted n8n, your vectors are covered by the same pg_dump and tested by the same restore procedure. With Qdrant, you need to set up and test a second mechanism: its collection snapshots, to be triggered, stored, and restored separately. Nothing insurmountable, but it's one more procedure that must exist the day the disk fails.

Comparison table

Criterion	pgvector	Qdrant
Nature	PostgreSQL extension	Dedicated vector engine (Rust)
n8n node	Supabase Vector Store / PGVector Vector Store	Qdrant Vector Store
Services to operate	None extra if Postgres already exists	One additional container
Joins with business data	Native (SQL)	Through your code / workflows
Transactions	Yes (PostgreSQL ACID)	No (per-point/collection guarantees)
Metadata filtering	SQL WHERE clauses	Payload filtering integrated into the index, rich conditions
Quantization	Not built in	Scalar, binary, product
Backups	pg_dump already in place	Qdrant snapshots to set up
Comfort zone	Up to a few million vectors	From modest to very large volumes
Best fit	Teams already on Postgres/Supabase, classic document RAG	Large corpora, complex filters, vector search as a central service

Beware of benchmarks: test on your own data

The numbers-heavy comparisons floating around — often published by the vendors themselves — deserve skepticism. Academic research on the topic is clear: the reference study by Aumüller, Bernhardsson, and Faithfull, "ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms", published in Information Systems in 2020, shows that the performance of approximate search algorithms depends heavily on the dataset (dimensionality, distribution, metric) and on the recall/speed trade-off chosen: an algorithm that dominates on one dataset at a given recall level can be dominated elsewhere. In other words, no generic ranking predicts what your corpus, with your embeddings and your filters, will do in production. The work of Johnson, Douze, and Jégou on similarity search at very large scale (IEEE Transactions on Big Data, 2019) makes the same point from another angle: spectacular gains come from optimizations that are highly dependent on hardware and context. The good practice for an n8n project: build a small set of reference questions, measure recall and latency on your real data with each candidate, and decide on that basis rather than on a marketing chart.

Our honest recommendation

Below a few million vectors — which covers the vast majority of RAG projects built with n8n —, pgvector is more than enough. An enterprise document RAG, even fed thousands of PDFs, rarely exceeds a few hundred thousand chunks: at that scale, the Postgres extension delivers comfortable latencies, backups already in place, and zero extra services. It's the default choice we make in our complete RAG guide with Supabase, and the one behind the RAG Assistant Pack ($119), whose PDF ingestion into Supabase pgvector workflow ships the full chain ready to import. The same reasoning applies to a Notion-to-vector-store sync: the typical volume of a workspace doesn't justify a dedicated engine.

Qdrant is justified when one of these signals appears: a corpus counted in millions of vectors and still growing; rich, systematic metadata filters on every query; a hard memory constraint that quantization solves elegantly; or an organization where vector search becomes a shared service across several applications, with its own lifecycle. In those cases, the operational cost of the extra service pays for itself many times over.

And if you're still hesitating: start with pgvector. n8n's vector store nodes make the migration to Qdrant cheap the day those signals show up — you'll just re-ingest the corpus, which your ingestion pipeline already knows how to do.