As of release 1.90.0, Supabase nodes can use a custom schema instead of the default “public” database schema. However, the Supabase vector nodes didn’t get this upgrade.
My use case:
I want to store vectors in a table in a schema other than public.
I think it would be beneficial to add this because:
Adding custom schemas to the Supabase vector nodes would allow for better segmentation of data. Being forced to only use “public” leads to a cluttered database.
I ran into the same limitation — the Supabase Vector Store node is hardcoded to the public schema with no option to change it.
The workaround: bypass the node entirely and use HTTP Request nodes with Supabase’s RPC endpoint.
This gives you full control over which schema, table, and match function you call.
1. Create your match function in your custom schema:
-- Example: schema "my_app"
CREATE OR REPLACE FUNCTION my_app.match_documents(
query_embedding vector(1024),
match_count int DEFAULT 5,
match_threshold float DEFAULT 0.02
)
RETURNS TABLE (
id bigint,
content text,
metadata jsonb,
similarity float
)
LANGUAGE sql STABLE
AS $$
SELECT
id,
content,
metadata,
1 - (embedding <=> query_embedding) AS similarity
FROM my_app.documents
WHERE 1 - (embedding <=> query_embedding) > match_threshold
ORDER BY embedding <=> query_embedding
LIMIT match_count;
$$;
2. Import this workflow in n8n (copy-paste ready):
The key header is Content-Profile: my_app — this tells the Supabase PostgREST API to route the RPC call to your custom schema instead of public. For inserts, use the same header.
Bonus benefits over the native node:
Full schema control
Custom match function logic (filters, joins, hybrid search)
Faster execution (no n8n sub-chain overhead)
Works with any embedding dimension or provider
Not ideal that we need a workaround for something that should be a simple dropdown in the node, but this approach is production-stable and actually gives you more flexibility.
