n8n + Qdrant: A Vector Search Node for Real Workflows

Qdrant is a vector database for similarity search. The n8n Qdrant node lets a workflow embed text, store vectors, and run similarity queries. The right pattern for AI agent memory, RAG (retrieval-augmented generation), and semantic search.

What Qdrant does
The n8n Qdrant node
A RAG example
Agent memory example
The operational considerations
The embedding model choice
The Qdrant collection design
FAQ

What Qdrant does

Qdrant stores high-dimensional vectors (typically embeddings from a language model) and answers similarity queries: “find me the 10 vectors most similar to this one”. The use cases:

Semantic search. Find documents similar to a query, not just keyword matches.
RAG. Retrieve relevant context for a language model based on the user’s question.
Agent memory. Store an agent’s past interactions and find the most relevant ones for the current task.
Recommendation. Find products, articles, or videos similar to one the user liked.

The n8n Qdrant node

The node has three operations:

Insert vectors. Embed text (using an embedding model), store the vector in Qdrant with metadata.
Search vectors. Embed a query, find the most similar vectors in Qdrant.
Delete vectors. Remove vectors by ID or filter.

The right architecture:

A trigger (webhook, schedule, message) fires.
The workflow embeds the incoming text (OpenAI, Cohere, or a local embedding model).
The Qdrant node stores or queries the vectors.
The workflow uses the results (logs them, sends them to a language model, etc.).

A RAG example

The right pattern for RAG in n8n:

Ingest. A schedule node fires every hour. The workflow reads new documents from S3. Each document is chunked, embedded, and stored in Qdrant.
Query. A webhook receives a user question. The question is embedded. The Qdrant node finds the top-5 most similar chunks. The workflow passes the chunks + the question to a language model. The model answers based on the context.

This is the right architecture for a chatbot that answers questions about a specific knowledge base.

Agent memory example

The right pattern for agent memory in n8n:

Store. After each agent interaction, embed the interaction’s key facts. Store in Qdrant with metadata (timestamp, agent ID, etc.).
Recall. When the agent receives a new task, embed the task. Query Qdrant for the top-K most similar past interactions. Pass them to the agent as context.

This is the right architecture for an agent that learns from past interactions.

The operational considerations

The four things to plan for:

Qdrant hosting. Run Qdrant on a dedicated VM (not a container that gets killed), or use Qdrant Cloud. The team that runs Qdrant in a serverless function has data loss.
Embedding model cost. Every insertion and query costs an embedding API call. The team that uses OpenAI embeddings at scale has a non-trivial bill.
Vector index size. A Qdrant collection with 10 million vectors needs significant RAM. Plan capacity.
Backup. Qdrant’s snapshots are not free; set up regular snapshots to S3 or similar.

The embedding model choice

The right embedding model for n8n + Qdrant depends on the use case:

OpenAI text-embedding-3-small. 1536 dimensions, fast, cheap ($0.02/1M tokens). The right choice for most teams.
OpenAI text-embedding-3-large. 3072 dimensions, more accurate, more expensive. The right choice for semantic search where accuracy matters.
Cohere embed-english-v3.0. 1024 dimensions, fast, similar accuracy to OpenAI. The right choice for teams that prefer Cohere.
Local models (sentence-transformers, all-MiniLM-L6-v2). Free, runs on your hardware. The right choice for teams that want to avoid API costs or have privacy requirements.

The team that uses OpenAI embeddings for production has the simplest path. The team that wants cost savings or data privacy uses local models.

Important: when changing embedding models, you must re-embed all existing documents. The vectors from different models are not comparable.

The Qdrant collection design

The right schema for a Qdrant collection:

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

The right metadata design:

Document ID. A unique identifier (UUID, URL, hash).
Source. Where the document came from (file path, URL, etc.).
Timestamp. When the document was added.
Tags. Categorical labels for filtering.
User ID. For multi-tenant systems, the user/tenant ID for isolation.

The team that designs the metadata right has flexible filtering and fast queries. The team that dumps documents without metadata has a database that’s hard to query and manage.

FAQ

What is Qdrant?

An open-source vector database written in Rust. It stores high-dimensional vectors and answers similarity queries. The team that needs a production-grade vector store uses Qdrant, Pinecone, Weaviate, or Milvus.

How does n8n connect to Qdrant?

Through the n8n Qdrant node. The node has operations for insert, search, and delete. Configure the Qdrant URL and API key in the n8n credentials.

Can I use Qdrant for agent memory?

Yes. Embed each agent interaction’s key facts and store in Qdrant. On a new task, embed the task and query for the top-K similar past interactions. The team that uses this pattern has an agent that remembers across sessions.

Is Qdrant better than Pinecone?

Different tradeoffs. Qdrant is open-source, self-hostable, and fast. Pinecone is managed, simpler to operate, and more expensive. The team that wants control uses Qdrant; the team that wants simplicity uses Pinecone.

How much does OpenAI embedding cost?

text-embedding-3-small: $0.02 per 1M tokens. text-embedding-3-large: $0.13 per 1M tokens. The team that embeds 1M tokens per day with the small model pays $0.60/month; with the large model, $3.90/month.

Can I run Qdrant in Docker?

Yes. The official Qdrant Docker image is a single container; it handles persistence via a mounted volume. The team that runs Qdrant in Docker Compose has a working deployment.

What’s the difference between Qdrant and Pinecone?

Qdrant is open-source and self-hostable; Pinecone is managed. Qdrant gives more control; Pinecone gives less operational overhead. The team that picks Qdrant saves money and has control; the team that picks Pinecone has a managed service.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: