Connecting Weaviate to n8n: the vector database that does hybrid search without SQL

Hybrid search for RAG solves a real problem: vector search alone misses queries that contain an exact reference, an error code, or a rare proper name, because an embedding model encodes meaning, not characters. The solution we detail in that article relies on Postgres/Supabase: a SQL function that queries a tsvector index and pgvector in parallel, then merges the two lists with Reciprocal Rank Fusion. It works very well — but you have to write it by hand. Weaviate offers the same idea without writing any SQL: its native node in n8n embeds BM25 + vector hybrid search directly configurable in the interface, with an alpha parameter that tunes the balance between the two engines. Here's how to connect it and use it in an n8n RAG pipeline.

What Weaviate is, in one sentence

Weaviate is an open source vector database designed from the ground up to combine semantic search and keyword search in the same engine, rather than as an extension bolted onto a relational database after the fact. It deploys as a Docker container, exposes an HTTP API (port 8080 by default) and a faster gRPC API for high volumes (port 50051 by default), and offers a managed cloud tier for anyone who would rather not operate it themselves.

n8n added a dedicated Weaviate Vector Store node to its LangChain nodes, and then, in a node update merged in early January 2026, real native hybrid search support — not a workaround, but a feature of Weaviate's own query protocol exposed directly in the n8n interface.

The Weaviate node in n8n: four uses

Like n8n's other vector stores, the Weaviate Vector Store node works in several distinct modes, chosen based on where the node sits in your workflow:

• Insert Documents: ingests documents (text + metadata) with their embeddings into a Weaviate collection. Used at the end of a chunking pipeline.
• Get Many: retrieves a batch of documents, useful for inspecting or maintaining the collection.
• Retrieve Documents (as Vector Store for Chain/Tool): connected to a Question and Answer Chain to fetch relevant passages before answering.
• Retrieve Documents (as Tool for AI Agent): connected directly to the tool connector of an AI Agent, so the agent itself decides when to query the knowledge base.

It's this last mode — retrieval as an agent tool — that exposes the hybrid search settings.

Connecting: self-hosted Docker or Weaviate Cloud

Weaviate credentials in n8n separate the HTTP layer from the gRPC layer:

• HTTP: host (domain or IP of your instance), port (8080 by default), and an HTTPS toggle.
• gRPC: host and port (50051 by default), used by the client for higher-throughput operations.
• API key: required as soon as the instance isn't open without authentication — mandatory on Weaviate Cloud, also recommended when self-hosting once the container is exposed beyond localhost.

For a self-hosted setup next to an existing n8n instance, a minimal docker-compose.yml is enough: a Weaviate service with a persistent volume for the data, ports 8080 and 50051 exposed on the internal network shared with n8n, and the API key enabled via the container's environment variables (AUTHENTICATION_APIKEY_ENABLED, AUTHENTICATION_APIKEY_ALLOWED_KEYS). This is the same deployment logic as for Qdrant: one more container next to your n8n VPS, with its own backups to schedule — Weaviate has its own backup mechanism, separate from pg_dump.

Native hybrid search: the alpha parameter

This is the real differentiator compared to n8n's other vector stores. When you configure the node in retrieval mode, several fields appear to enable and tune hybrid search:

• Hybrid query (hybridQuery): the query text sent simultaneously to the lexical (BM25) engine and the vector engine.
• Alpha: from 0 (purely keyword-based search) to 1 (purely vector-based search), defaulting to 0.5 — a balance between the two.
• Fusion type (fusionType): the method for combining the two rankings (rank-based, similar to the Reciprocal Rank Fusion described in our hybrid search article, or relative-score).
• Query properties (queryProperties): the text fields the lexical portion of the search runs against, so irrelevant metadata doesn't get indexed as keywords.
• Maximum vector distance and auto-cutoff (maxVectorDistance, autoCutLimit): to discard results that are too far off rather than returning a fixed top-k that includes noise.

Concretely, an alpha of 0.3 will favor a chunk that contains the exact product reference cited in the question, even if its semantic score is average — exactly the behavior our hybrid search article builds by hand with a SQL function and RRF. Here, it's tuned with a single form field.

Why it matters: single-signal search has a documented limit

This isn't a cosmetic refinement. A study published in the proceedings of the 10th International Conference on Communication and Information Processing (ACM, 2024), "Evaluating Sparse and Dense Retrieval in Retrieval-Augmented Generation Systems: A Study" by Wang, Dai, Ke, and Zheng (see on Google Scholar), compares dense and sparse (BM25-style) retrieval in RAG pipelines and shows that choosing the right retrieval algorithm, matched to the query type and hardware constraints, directly affects the quality of downstream generated answers. In other words: no single retrieval engine, however good, covers every query pattern in real-world usage — hence the value of being able to combine both without building a fusion pipeline by hand.

Weaviate, pgvector, or Qdrant: how to decide

All three options have a native node in n8n and deploy via Docker. The deciding factor isn't raw performance — all three comfortably handle a typical n8n RAG project's load — but which piece of work you'd rather not code yourself:

Priority	Recommended choice
Avoid one more service, keep everything in Postgres/Supabase	pgvector
Hybrid search out of the box, no fusion SQL to write	Weaviate
Complex metadata filtering at very large scale	Qdrant

None of the three is a bad choice: they're three different ways of paying the same cost (a service to operate, a function to write, or a parameter to tune) depending on what your project prioritizes.

Building the full pipeline

Once the connection is set up, the pipeline follows the usual n8n RAG pattern: ingesting source documents (PDFs, web pages, Notion exports) through a chunking workflow, generating embeddings, and inserting them into Weaviate via the node in Insert mode. On the query side, an AI Agent with the Weaviate node wired in as a tool, alpha tuned to your users' question patterns, answers while citing the retrieved passages — the same pattern detailed in our PDF RAG guide, with a different search engine underneath.

The RAG Assistant Pack (€119) ships these four ready-to-import workflows — PDF ingestion, chatbot with citations, Notion sync, /ask API — configured with pgvector by default but adaptable to Weaviate by simply swapping the vector store node and its credentials. For anyone starting a project where hybrid search is a day-one requirement rather than an optimization added later, it's the only one of the three engines that provides it without building the fusion layer yourself.