Which embedding model should you choose for your n8n RAG (Supabase pgvector)?

In an n8n RAG pipeline, the choice of embedding model is a structural decision made in the very first ingestion workflow — and often by default, keeping whatever model is pre-filled in the node without a second thought. Yet it's this model that determines the quality of the vector search, the size of the pgvector index, the cost of every ingestion run, and the dimension of the vector(n) column declared in Supabase. And unlike the LLM prompt, which you can tweak in two minutes, changing it later means re-indexing the entire corpus. Better to choose it with your eyes open.

Reminder: the role of embeddings in a RAG pipeline

An embedding is the numerical representation of a piece of text: a model turns a sentence or a document chunk into a vector of hundreds or thousands of numbers, built so that two texts close in meaning produce vectors close in space. That's what lets vector search find "the passages that talk about the same thing" as a question, even with no keyword in common.

The idea of producing sentence embeddings that are directly comparable to each other was popularized by the seminal Sentence-BERT paper by Reimers and Gurevych (EMNLP 2019, see on Google Scholar): encode each text once into a reusable vector, making the comparison of thousands of candidates near-instantaneous. Every modern embedding model, proprietary or open source, descends from this approach.

In n8n, the model is set in the Embeddings node (Embeddings OpenAI, Embeddings Ollama, etc.), wired to the Vector Store node. And it comes into play at two points of the pipeline described in our Supabase pgvector RAG guide:

• at ingestion: each chunk produced by the document chunking step is converted into a vector and inserted into the Supabase table;
• at query time: the user's question is converted into a vector with the same node, then compared against the stored vectors via match_documents.

The golden rule: same model at ingestion and at search

This is the non-negotiable constraint of the whole decision: the model used to index and the model used to search must be identical. Each model projects texts into its own vector space — a vector produced by text-embedding-3-small and a vector produced by an Ollama model have mathematically nothing to do with each other, even if they happen to share the same dimension. Comparing the two yields similarity scores that look like scores… but measure nothing.

Two practical consequences:

• Switching models = re-indexing everything. You have to run the entire corpus through the ingestion workflow again and recreate the vector(n) column if the dimension changes. On a large corpus, that's time and money — hence the value of testing before committing.
• Check consistency across workflows. In n8n, ingestion and chat are often two separate workflows, each with its own Embeddings node. If someone changes the model on one side without touching the other, the RAG keeps "working" (no error) but returns passages unrelated to the questions. It's a nasty silent bug.

The criteria that actually matter

Quality on your language

This is the most underestimated criterion. Many embedding models are trained predominantly on English: on a French corpus, an explicitly multilingual model often makes a clear difference. If your documentation mixes French and English (a common case: internal docs in French, technical documentation in English), multilingual support becomes downright essential — a good multilingual model brings a question in French close to an English passage that answers it.

The vector dimension

Each model produces vectors of a fixed dimension, and that dimension has very concrete effects on the Supabase side:

• it determines the vector(n) column declared in the table — 1536 for text-embedding-3-small by default, for instance;
• it drives the size of the table and above all of the pgvector index: vectors twice as large mean an index roughly twice as heavy, more RAM consumed and slightly slower searches, whatever the index type you pick (HNSW or IVFFlat).

A larger dimension captures more nuance in theory, but on a reasonably sized corpus, the quality gap between a good "compact" model and a very high-dimensional one is rarely the limiting factor — chunking and reranking usually weigh more.

Cost, latency and hosting

Embeddings are billed per million tokens, at rates far below those of generation LLMs — but ingesting a large corpus, re-indexing runs included, eventually shows up on the bill. Latency mostly matters on the query side: every user question goes through an embedding call before the search.

Finally, hosting: a cloud API (OpenAI, Cohere, Mistral, Google) is simple and fast to integrate, but every chunk of your documentation passes through a third-party server. For sensitive data, an open-source model served locally is the only genuinely airtight option.

The main model families

OpenAI embeddings are the default choice in the n8n ecosystem: text-embedding-3-small (1536 dimensions by default) covers most cases very well, including non-English corpora, and text-embedding-3-large steps up in quality for demanding corpora. A useful particularity: these models accept a dimensions parameter that lets you shrink the vectors they produce — handy to lighten the pgvector index — provided, golden rule again, you use exactly the same reduced dimension at ingestion and at query time.

The proprietary alternatives — Cohere (known for its multilingual strength), Mistral (a European player, a data-residency argument), Google — all offer good-quality embedding APIs. Wiring them into n8n goes through the matching Embeddings node when one exists, or an HTTP Request node otherwise.

Open-source models running locally via Ollama: models like nomic-embed-text run on your own machine, called from the Embeddings Ollama node. Two massive arguments: confidentiality (no data leaves your infrastructure) and zero API cost — ingesting an entire corpus only costs machine time. The tradeoff: your server takes the load, and multilingual quality varies a lot from one model to the next. Our guide on n8n + Ollama for a local LLM without an API key covers the setup, which applies to embeddings too.

Comparing objectively: MTEB, with caution

To compare dozens of models without testing them one by one, the public reference is MTEB (Massive Text Embedding Benchmark), introduced by Muennighoff and his co-authors in 2022 (see on Google Scholar): a test bench that evaluates embedding models across dozens of tasks (retrieval, classification, clustering…) and whose public leaderboard is regularly updated with new models.

The caveat that comes with it: a good average MTEB score does not guarantee the best result on your corpus. The leaderboard aggregates domains and languages that aren't yours. The right method: use MTEB to shortlist 2 or 3 credible candidates (filtering on the retrieval tasks and languages that concern you), then decide between them on a sample of real questions: index the same subset of documents with each model, ask 20 to 30 real questions, and compare the passages that come back. One hour of testing saves months with the wrong model.

On the n8n side: the consistency points to lock down

Concretely, in a workflow like our PDF ingestion into Supabase pgvector, three elements must stay aligned at all times:

1. The Embeddings node of the ingestion workflow — the model (and the optional dimension parameter) producing the stored vectors.
2. The vector(n) column of the Supabase table — its dimension must match exactly the dimension of the vectors produced, otherwise pgvector rejects the insert. Creating this table is covered in our guide on connecting n8n to Supabase.
3. The Embeddings node of the chat workflow — same model, same dimension, no exceptions.

A simple reflex: record the model name in each chunk's metadata at ingestion time. The day a doubt creeps in ("what was this table indexed with, again?"), the answer is right there in the database.

Going further

The choice of embedding model is one of the three foundations of a RAG that answers correctly, along with chunking and retrieval quality — if the retrieved passages remain disappointing despite a good model, the next step is often reranking. The RAG Assistant Pack (€119) provides the ingestion, chat-with-citations, Notion sync and question-answering API workflows already wired to Supabase pgvector: the Embeddings node is isolated and documented there, which lets you test several models on your own corpus by changing a single parameter — then re-index cleanly once the right candidate is identified.