Strange Supabase Vector Store behavior in n8n: Queries the wrong table despite correct configuration

Questions
,
1

TL;DR: My n8n Supabase Vector Store node is querying a different table than the one I configured it to use. Looking for help debugging this behavior.

Hey folks,

I’ve run into a bizarre issue with the Supabase Vector Store node in n8n that I’m hoping someone can help me understand.

The Problem: I’ve configured my Vector Store node to query a table called insta_rag_embedded, but when I run the workflow, it’s actually querying a completely different table called vector_embeddings. I’ve triple-checked my configuration, and it’s definitely set to insta_rag_embedded.

What I’ve Confirmed:

  • The UI clearly shows the table name is set to insta_rag_embedded
  • The Operation Mode is set to “Retrieve Documents”
  • The results being returned match records from vector_embeddings (confirmed by directly querying the database)
  • Both tables have similar schemas (id, content, embedding, metadata) but different content

What I’m searching for: A query like “Can I rent a surfboard at Villa —?” returns results that contain content about surfboard rentals at — but this content is in the vector_embeddings table, not in my configured insta_rag_embedded table.

My Questions:

  1. Has anyone experienced this weird “table switching” behavior before?
  2. Could there be some caching issue in n8n?
  3. Is there perhaps a hardcoded table name somewhere in the node’s code?
  4. Could the vector embedding model or operation mode be causing this?

I’m completely stumped as this seems to defy the basic configuration I’ve set up. Any ideas or debugging suggestions would be much appreciated!

Screenshot 2025-04-12 at 11.08.27
Screenshot 2025-04-12 at 11.08.27870×1358 67.4 KB

2

I’m seeing the exact same issue.

My Vector Store node is set to a specific table, but the results are clearly coming from a different one.

3

Let me know if you ever find a solution. Will post here if I do on my side.

4

Hey @Maxime_Prn Welcome to the community :wave:

One idea would be to check the contents of the SQL function match_documents which is what the Supabase vector store tool calls by default.

If you’ve followed the Supabase Langchain quickstart, you can see this match_documents function has the table name “documents” hardcoded as part of its query. My guess is if you have something similar, this could possibly explain the weird behaviour you’re seeing.

5

Right on point!

My match_document function was defined as follow:

SELECT
    id,
    content,
    metadata,
    1 - (embedding <=> query_embedding) AS similarity
FROM vector_embeddings
ORDER BY embedding <=> query_embedding
LIMIT match_count;

That’s why it was only looking through my “vector_embeddings” table.

Thanks Jim!