Connecting Qdrant to n8n: the complete dedicated vector store guide

Qdrant is probably the most natural dedicated vector database to plug into n8n: open source, a native node, a Docker container running next to your instance, and a managed cloud offering for those who don't want to operate anything. If you're still hesitating between Qdrant and pgvector, our Qdrant vs pgvector comparison details the decision criteria; this guide takes the decision as made and walks through the practical steps: launching Qdrant, creating the credential, inserting documents, querying the collection from an AI Agent, and filtering on metadata. From zero to your first successful retrieval.

Why Qdrant for an n8n RAG

Three arguments come up consistently among those who pick Qdrant:

• Open source and self-hostable. The engine (written in Rust) runs as a single Docker container on the same server as n8n. Your vectors stay on your infrastructure, with no mandatory cloud dependency — unlike Pinecone, which is fully managed.
• Payload filtering built into the index. Every Qdrant point carries a freely structured metadata payload, and filters (must/should/must_not, ranges, exact matches) are applied while traversing the HNSW index, not after the fact on the results. For a multi-tenant or heavily filtered RAG, this is the decisive argument.
• Dedicated-engine performance. Qdrant is built on the HNSW algorithm described by Malkov and Yashunin in Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs (IEEE Transactions on Pattern Analysis and Machine Intelligence, 2020, see on Google Scholar): a hierarchical multi-layer graph that delivers logarithmic search complexity, which explains why latency stays low even as the collection grows substantially.

Step 1: launch Qdrant

With Docker, next to n8n

The simplest approach is to add the service to the docker-compose.yml that already hosts your n8n:

services:
  qdrant:
    image: qdrant/qdrant:latest
    restart: unless-stopped
    ports:
      - "6333:6333"
    environment:
      - QDRANT__SERVICE__API_KEY=change-me-long-random-string
    volumes:
      - qdrant_storage:/qdrant/storage

volumes:
  qdrant_storage:

Three things not to miss:

1. The persistent volume: without it, your collections vanish every time the container is recreated.
2. The API key via QDRANT__SERVICE__API_KEY: Qdrant starts without authentication by default, which is acceptable on an internal Docker network but never if port 6333 is publicly exposed.
3. The dashboard: once running, http://your-server:6333/dashboard provides a web interface to inspect collections and points — invaluable for debugging an ingestion run.

On Qdrant Cloud

If you'd rather host nothing, Qdrant Cloud provides a managed cluster (with a free tier that's enough for prototyping). After creating the cluster, grab two pieces of information: the cluster URL (of the form https://xxx-xxx.region.cloud.qdrant.io:6333) and an API key, generated from the cluster's API Keys tab. Those are exactly the two fields n8n will ask for.

Step 2: create the Qdrant credential in n8n

In n8n, create a Qdrant API credential with two fields:

• Qdrant URL: the address of your instance. Watch out for the Docker case: if n8n also runs as a container on the same network, the host is the service name (http://qdrant:6333), not localhost — localhost would refer to the n8n container itself.
• API Key: the key set in the Docker environment or generated on Qdrant Cloud. The field can stay empty for an unauthenticated local instance, but you might as well pick up the good habit right away.

The built-in connection test immediately validates the URL + key pair. This credential will then be used across all the node's modes, insertion and retrieval alike.

Step 3: insert documents (Insert mode)

The Qdrant Vector Store node in Insert Documents mode is the destination of the ingestion pipeline. It's configured with the credential created above and a collection name — if it doesn't exist, the node creates it with the dimension of the first embedding it receives. Two sub-nodes plug into it:

1. An Embeddings node (OpenAI, Mistral, Ollama…) that vectorizes each fragment — your choice of embedding model determines the collection's dimension and can no longer change without re-ingestion.
2. A Default Data Loader (with its Text Splitter) that loads the source document, splits it into chunks — size and overlap are covered in our chunking guide — and attaches the metadata.

The metadata defined in the Data Loader (source, client, date, document type) lands in each Qdrant point's payload, under the metadata key, with the chunk text stored under content. That payload is what makes the filtering in step 5 possible.

Step 4: query the collection

The same node switches to retrieval mode, with three variants:

Mode	Usage
Retrieve Documents (As Tool for AI Agent)	Expose the collection as a tool for an AI Agent, which decides on its own when to search — the core of an agentic RAG
Retrieve Documents (As Vector Store for Chain/Tool)	Feed a structured question-answering chain, without agent autonomy
Get Many	Directly fetch the N chunks closest to a query, for downstream processing

For a documentation assistant, the "As Tool for AI Agent" mode is the standard: give the tool an explicit name and description ("search the internal product documentation"), because that description is what the model uses to decide whether to call the tool. The Embeddings node plugged in on the retrieval side must be strictly the same model as the one used for ingestion — a query vectorized in a different space would return random results. This ingestion/retrieval separation principle is the same as in our RAG guide with Supabase; it's also the whole point of the architecture laid out by Lewis et al. in Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020, see on Google Scholar): the quality of the final answer depends first and foremost on the relevance of the retrieved passages.

Step 5: filter on the payload

This is Qdrant's specialty. In the node's options in retrieval mode, the Search Filter field accepts a JSON filter in Qdrant's native format:

{
  "must": [
    { "key": "metadata.client_id", "match": { "value": "acme" } },
    { "key": "metadata.doc_type", "match": { "value": "contract" } }
  ]
}

The keys point into the payload with the metadata. prefix (where the Data Loader stored your fields). Since the filter is evaluated while traversing the index, search stays fast even when highly selective — exactly the behavior you want for multi-tenancy. Values can be dynamic through an n8n expression ({{ $json.client_id }}), which allows a single workflow to serve every client. For the overall strategy (which metadata to attach, how to structure it), see our article on metadata filtering in RAG.

Production best practices

• Name collections explicitly: product_docs_openai_small_v2 states the corpus, the embedding model, and the version — indispensable the day several collections coexist.
• Lock the dimension: one collection = one embedding model. Switching models = new collection + full re-ingestion, never a mix.
• Schedule snapshots: unlike pgvector, which is covered by pg_dump, Qdrant has its own backup mechanism. A POST /collections/{name}/snapshots call (triggerable from a scheduled n8n workflow with an HTTP Request node) creates a restorable snapshot; store it off the server.
• Watch corpus/index consistency: documents deleted at the source, stale versions — our guide on keeping a RAG index up to date covers upsert and purge strategies.

When to prefer pgvector

Let's be honest: if your stack already runs on Postgres or Supabase, if your corpus counts tens or hundreds of thousands of vectors, and if your filters stay simple, pgvector does the same job with no extra service to operate and no dedicated backup mechanism. Qdrant takes the lead on large volumes, rich and systematic payload filters, and architectures where vector search is a service in its own right. The full Qdrant vs pgvector comparison walks through these criteria one by one.

Summary

Connecting Qdrant to n8n comes down to four moves: a Docker container (or a Qdrant Cloud cluster), a URL + API key credential, the Qdrant Vector Store node in Insert mode plugged into a Data Loader and an embedding model, then the same node in Retrieve mode as an AI Agent's tool — with, as a bonus, the payload filters that made the engine's reputation. The complete pipeline (ingestion, chunking, answering agent with citations) is exactly the architecture shipped in the RAG Assistant Pack (€119): its workflows use Supabase pgvector by default, and moving to Qdrant boils down to swapping the storage node and recreating the credential — the rest of the pipeline doesn't change.