I’d like to ask about using different embedding models together. Specifically:
Is it possible to generate embeddings with one model and then perform retrieval/search using another embedding model?
If yes, are there compatibility issues between the vector spaces of different models?
What are the potential downsides (e.g., reduced accuracy, performance mismatches)?
Are there best practices or recommended approaches for mixing models in this way?
Hey @Asha_Naon, while you wait for a response, here are some things that might help:
Automatically matched to your question.
Docs:
Forum:
@KaiS - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.
Hi @Asha_Naon ,
The short answer is no, you generally can’t mix different embedding models in the same vector database. If you use model A to embed your files and model B to search, their vectors won’t match up and your search results will be a mess.
Even two different embedding models from the same provider (like two OpenAI models or two Gemini models) still live in separate vector spaces, so they also won’t be compatible for this kind of cross‑model search.
But there is one cool exception right now: Voyage 4
They built it so all their models share the exact same embedding space. This is huge because you can use their biggest model to index your database for high accuracy, and then use their smallest, cheapest model to handle user queries to keep things fast. They understand each other perfectly.
Since n8n doesn’t have a native Voyage node yet, I actually built a community node for it called n8n-nodes-embeddings-voyageai. You can install it directly from your n8n settings under Community Nodes.
Let me know if you need any help setting it up!
Hi @Asha_Naon
No, the query has to be embedded by the same model that embedded the documents. Every model builds its own vector space, so a vector from model A and one from model B aren’t comparable even when the dimension count happens to match, and similarity scores come out close to random. When the dimensions differ the store errors out instead, like “different vector dimensions 1536 and 768” on pgvector.
One embedding model per index or collection is the rule. Set the same Embeddings sub-node on the insert side and on the retrieval side of the Vector Store node.
To move to a better model, create a fresh index at that model’s dimension, re-embed the whole corpus into it, then switch retrieval over. Don’t write the new vectors into the old index.
If you do need several models (multilingual vs code, cheap vs accurate), keep a separate collection per model and route the query to the matching one. The safe place to mix models is the rerank step: embed and retrieve with one model, then rerank the top hits with another.
More on the setup here:
https://axshul.site/n8n/guide/vector-stores-and-rag/
what do you mean when you say about voyage 4?
too expensive if i need to retrieve a lot of query for my public chatbot 
If you mix different embedding models in the same vector database, they usually don’t “speak” the same vector language, so your search results get noisy or just wrong. That’s why most docs (including n8n’s) say: pick one model and use it for both storing and querying.
Voyage 4 is special because all models in that family share one embedding space: voyage-4-large, voyage-4, voyage-4-lite, and voyage-4-nano all produce compatible vectors. That means you can index your documents once with voyage-4-large for the best quality, then use voyage-4-lite or voyage-4-nano for user queries to save cost and latency, without breaking retrieval accuracy.
oh woww, really? thanks Jay I will try this!