Best Embedding Model for n8n RAG: OpenAI vs Gemini vs Local (2026)

You built a working RAG pipeline in n8n, picked Embeddings OpenAI because it was the obvious default, and never stopped to ask whether Gemini would cost less or whether a local model would keep your documents off a vendor's servers. Choosing between n8n rag embeddings options (OpenAI, Google Gemini, Ollama) is a trade across four verifiable axes, not a leaderboard ranking.

That one skipped decision now sits under every query your pipeline processes. If your knowledge base grows, the cost to re-index at a different dimension or price tier grows with it.

What does an embedding model actually do in n8n RAG?#

An embedding model converts each text chunk and each query into a vector, a list of numbers, so a vector store can find the chunks most similar to a given query by measuring distance. In n8n, you attach an embeddings sub-node directly to your vector store node, and that sub-node is where every insert and every query runs.

The model you wire in determines the shape of every vector in your index, the size of your store, and whether your documents ever leave your machine. Every query pays the embedding cost twice: once to embed the incoming query, and once per chunk at indexing time. Indexing is a one-time cost per chunk; queries are the ongoing bill.

See n8n vector store and embeddings sub-node pairing explained for a full walkthrough of how these two nodes connect.

Which embedding nodes does n8n give you?#

n8n ships three embeddings nodes as cluster sub-nodes: Embeddings OpenAI, Embeddings Google Gemini, and Embeddings Ollama. Each one attaches at the same point on your vector store node, exposes a Model field, and requires its own credential type, so swapping providers is mostly a question of which API key or base URL you wire in.

Each node is a drop-in option at the same attachment point on your vector store node. Swapping one for another is three clicks in the n8n canvas, but what happens to your existing vectors afterward is a different story.

Here is what each node needs to run:

• Embeddings OpenAI: an OpenAI API key. You can point it at OpenAI-compatible endpoints via a Base URL set on the credential.
• Embeddings Google Gemini: a Google Gemini (PaLM) API key.
• Embeddings Ollama: an Ollama base URL (typically http://localhost:11434).

OpenAI vs Gemini vs local: how do they compare on the numbers?#

The four axes that determine your build are dimensions, price per 1M tokens, max input context, and whether the model runs cloud or local. Dimensions fix your storage and schema, price drives the bill, context caps your chunk size, and cloud-versus-local decides whether documents leave your machine. Here they are in one table, traceable to primary sources (as of mid-2026):

Sources: OpenAI embeddings guide, OpenAI model pricing, Gemini embedding model docs, Gemini API pricing, Embeddings Ollama node docs, Nomic embed-text model card. Prices are perishable; verify on the vendor's page before indexing.

A quick cost illustration: embedding 1,000,000 tokens (roughly several thousand pages) costs $0.02 with text-embedding-3-small, $0.13 with text-embedding-3-large (6.5x the small price), $0.15 with gemini-embedding-001 (the most expensive cloud option here), and $0.00 with nomic-embed-text running locally. For a one-time index that size, the cloud cost is nearly trivial. Dimension count and privacy constraints matter more than the indexing cents.

All values sourced from OpenAI and Nomic official docs, as of mid-2026.

Why do vector dimensions and price matter more than benchmark scores?#

Public MTEB scores do not transfer to your specific corpus. A model that ranks well on a benchmark dataset may perform differently on your product documentation, customer emails, or internal knowledge base. The only way to know is to test on your own documents.

Dimensions and price give you concrete facts. A 3072-dim vector takes twice the storage of a 1536-dim vector and four times the storage of a 768-dim vector. If your pgvector or Qdrant store has a vector(1536) column and you insert 3072-dim vectors, the insert fails. Dimensions are a hard schema constraint, not a soft preference.

Price per 1M tokens matters most at scale. For a one-time index of a million tokens, the difference between $0.02 and $0.13 is $0.11. For a high-query-volume pipeline that re-embeds chunks on updates, that ratio compounds. Start cheap, test quality on your corpus, and only pay for more dimensions if testing shows you need them.

Higher dimensions can represent more nuance in the vector space. Whether that nuance improves retrieval for your documents is an empirical question, not a guaranteed outcome.

Why must you re-embed everything if you switch models?#

Switching embedding models after indexing means re-embedding your entire corpus from scratch. Two models produce vectors in different mathematical spaces with different dimensions, so a query vector from one model is meaningless against document vectors from another. There is no partial migration: query and document vectors must always come from the same model, or retrieval silently breaks.

This is a direct consequence of the dimension facts above: a 1536-dim query vector cannot be distance-compared to a 768-dim document vector. Even two models that both output 1536 dimensions place concepts in different positions within that space. Query and document vectors must come from the same model, always.

The first model you pick is the one you are committing to until you are willing to re-index everything. That framing shifts the decision from "which scores slightly better on benchmarks" to "which can I confidently live with."

Follow every step in order; skipping re-embed breaks retrieval silently.

Which embedding model should you pick for n8n RAG?#

For most solo operators building their first or second RAG pipeline, text-embedding-3-small is the right default: 1536 dimensions, $0.02 per 1M tokens (as of mid-2026), 8192-token context, and broad community support in n8n. It is not the highest-dimension option, but it is cheap enough that re-indexing later does not sting badly if you outgrow it.

Use Embeddings Ollama with nomic-embed-text when your documents must not leave your machine. The fully local RAG path with Ollama removes the API bill entirely and works offline. The trade is that you run and maintain the model yourself, and embedding throughput is bounded by local hardware.

Use text-embedding-3-large or gemini-embedding-001 only after you have tested that the extra dimensions actually improve retrieval on your specific corpus. Do not pay for 3072 dims on the assumption they will help.

On Gemini specifically: gemini-embedding-001 is notable because output dimension is configurable from 128 to 3072 via Matryoshka (output_dimensionality), and a free, quota-limited tier exists. Its paid price is $0.15 per 1M input tokens on the Gemini API pricing page as of mid-2026, which makes it the most expensive cloud option here, roughly 7x text-embedding-3-small. The 2048-token max input context is also lower than OpenAI or nomic-embed-text, which matters if your chunks are long.

Use Ollama when privacy or zero API cost outweighs operational effort.

Run through this branch before committing to any embedding model.

How do you set up and switch an embeddings node in n8n?#

Setting up any of the three n8n embeddings nodes takes under five minutes: attach the sub-node, add the credential, and pick the model. The two parts that actually bite you are the dimension match between the model and your vector store schema, and the re-index discipline you need every time you change the model later.

See the full RAG build walkthrough in this n8n customer support bot example to see these nodes wired end to end in a real workflow.

Step-by-step setup#

1. Open your RAG workflow, click the vector store node, and attach a sub-node. Select Embeddings OpenAI, Embeddings Google Gemini, or Embeddings Ollama.
2. Add the credential: an OpenAI API key, a Google Gemini (PaLM) API key, or your Ollama base URL in the Credential field.
3. Open the Model dropdown and select the model. For Ollama, the node prints the dimension count next to each name (for example "nomic-embed-text (768 Dimensions)").
4. Check your vector store column or collection dimension and confirm it matches the model output (1536, 3072, or 768). If your schema says vector(1536), a 3072-dim model will fail on insert.
5. Run your indexing workflow to embed all chunks, then fire a few test queries and inspect the top-k results.
6. If you change the model later, re-embed every chunk and re-upsert before switching production traffic. There is no shortcut.

On n8n Community Edition (free, self-hosted), none of the three embeddings nodes costs anything on the n8n side. Your embedding bill comes from whichever API you call. n8n Cloud Starter is €20/month billed annually. With Ollama and self-hosted n8n, the total infrastructure cost for the embedding layer is $0.

For how the same cost-vs-quality reasoning applies to the generation (chat) model layer, see Claude vs GPT vs Gemini for n8n AI agents.

Where to go from here#

Pick the embeddings node that matches your privacy and storage constraints now, not the one with the most impressive dimension count. Default to text-embedding-3-small until storage cost or a documented privacy requirement forces a change. If your documents are not sensitive, wire up Embeddings OpenAI with text-embedding-3-small and only revisit when your own corpus shows a real gap.