Supabase Vector Store Node ignores the Table Name field and always uses the "documents" table

[blinkin69]

Bug Description

The Supabase Vector Store Node in n8n does not respect the Table Name field. Regardless of what is entered in this field, the node always queries the default "documents" table.

Actual Behavior:
The node always queries the documents table, even if a different table name is configured.

To Reproduce

Steps to Reproduce:

Create two tables in Supabase: documents and custom_table.
Configure the Supabase Vector Store Node in n8n and set the Table Name field to custom_table.
Execute the workflow.
Observe that the node still fetches data from the documents table, ignoring the Table Name configuration.
Expected Behavior:
The node should query the table specified in the Table Name field (e.g., custom_table).

Expected behavior

The node should query the table specified in the Table Name field (e.g., custom_table).

Operating System

n8n cloud

n8n Version

1.75.2

Node.js Version

x

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @blinkin69,

We have created an internal ticket to look into this which we will be tracking as "GHC-645"

[Joffcom]

Hey @blinkin69,

This is possibly not an issue with the n8n application itself and more than likely a problem with the match function you are using, Can you check in Supabase to see what the function is doing I suspect it will have a FROM documents line in it which will be where this error is coming from.

[tedvo]

@Joffcom I think you are right. I have check the function match_documents and see it is using table documents.

-- Create a function to search for documents
create function match_documents (
query_embedding vector(1536),
match_count int default null,
filter jsonb DEFAULT '{}'
) returns table (
id bigint,
content text,
metadata jsonb,
similarity float
)
language plpgsql
as $$
#variable_conflict use_column
begin
return query
select
id,
content,
metadata,
1 - (documents.embedding <=> query_embedding) as similarity
from documents
where metadata @> filter
order by documents.embedding <=> query_embedding
limit match_count;
end;
$$;

[Joffcom]

Hey @blinkin69

That will be it you will need to update the function for this to work.

As this doesn't look to be a bug I will mark this as closed but I will also update the docs shortly to mention this as others may run into the same problem.

[Ankit-Mahadani]

any solutions?

[squarezw]

faced same situation, if the Table settings in n8n is not useful, can we change it to "match func name" instead of default function?

[flewis88]

Has anybody come up with a match_function which will pass in the selected table name and use the correct SQL table? Given there is a native Supabase integration in n8n with the table select, surely this has been investigated

[platnub]

You can achieve this with a custom query option like this:

[flewis88]

You can achieve this with a custom query option like this:

This is incredible! Exactly what I've been looking for. Will try today.

[platnub]

You can achieve this with a custom query option like this:

This is incredible! Exactly what I've been looking for. Will try today.

Make sure to fully edit the SQL command like I did below for my use case.

-- Create a function to search for documents
create function match_fortigate_documents (
  query_embedding vector(3584),
  match_count int default null,
  filter jsonb DEFAULT '{}'
) returns table (
  id bigint,
  content text,
  metadata jsonb,
  similarity float
)
language plpgsql
as $$
#variable_conflict use_column
begin
  return query
  select
    id,
    content,
    metadata,
    1 - (fortigate_documents.embedding <=> query_embedding) as similarity
  from fortigate_documents
  where metadata @> filter
  order by fortigate_documents.embedding <=> query_embedding
  limit match_count;
end;
$$;

[flewis88]

Definitely. In fact I have the respective functions set up already, just couldn't work out how to call them. I've been looking into the source code to see if table name is being passed to Supabase already and whether table name could be a variable in match_documents function