I have a n8n workflow that creates embeddings for the given pdf document. I’m using the PGVector store with models/gemini-embedding-001. Though n8n shows the default dimension for this model as 768, it is given error while saving. Hence I altered the vector database to have the dimension 3072. The store is successful, I could see the pdf file contents in the Postgres vector database, however when I retrieve using an n8n Agent node or the PG retrieve it isn’t returning any valid response. It is returning I cannot find any information about the topic in the provided documents. How to troubleshoot this ?
make sure the embedding node attached to your retrieval agent is strictly set to models/gemini-embedding-001. if your ingestion workflow saved 3072-dimension vectors but your agent is accidentally querying with a 768-dimension default, postgres won’t be able to match them and will return zero results.
and since you manually altered the dimension size of the postgres column to 3072, any old 768-dimension data sitting in there is going to break the search. you need to completely clear or drop that vector table, then run your ingestion workflow again so your pdfs are freshly embedded at the correct 3072 size.
The dimension mismatch is almost certainly your problem here. If you stored vectors at 3072 dimensions you need to make sure your retrieval node is also using the exact same embedding model with the same output dimensions, otherwise the cosine similarity math just doesn’t work and you get zero matches. Double check that the embedding credentials node connected to your PG Vector Retrieve or Agent node is pointing to the same models/gemini-embedding-001 config you used during ingestion. Also worth nuking the table and re-ingesting fresh after you changed the dimension to 3072, any rows created before that alter statement would have been truncated or malformed.
The best solution @vsk123 is to Change your PGVector dimension back to 768
Drop and recreate your vector table with the correct dimension:
-- Drop existing table (backup data first if needed!)
DROP TABLE IF EXISTS your_table_name;
-- Recreate with correct dimension
CREATE TABLE your_table_name (
id SERIAL PRIMARY KEY,
content TEXT,
metadata JSONB,
embedding vector(768) -- Changed from 3072 to 768
);
Re-ingest your PDF documents with the corrected table structure
Ensure your retrieval uses the same embedding model (models/gemini-embedding-001)
The reason the storage “succeeded” is that PostgreSQL with pgvector will accept vectors of different dimensions than specified - it just pads or truncates them, which completely breaks the semantic meaning of the embeddings. That’s why retrieval returns no results.
Verification Steps
After fixing the dimension, check your stored vectors:
SELECT array_length(embedding, 1) as dimension_count
FROM your_table_name
LIMIT 1;
Should return 768.
Test a simple query in your Agent/Retrieval node with a question you know is in the PDF
Check the similarity scores - you should see scores > 0 if matches are found
Let me know if you still have issues after fixing the dimension.
Hello,
Thank you for your prompt response. If I create a table with embedding vector (768), then I’m unable to store the pdf into the vector database. I’m getting the attached error during PG Store. I believe the output dimension is hardcoded to the default 3072 within the n8n nodes for the models/gemini-embedding–001 . I unable to store my pdf in the vector database with vector(768)>
Instead of using models/gemini-embedding–001,
Option-02
I tried to use text-embedding-005 (from Embeddings Google Vertex), I’m able to save the pdf file to the vector DB with dimension 768,. Retrieval works using the Retrieve PG node but the similarility score is quite low 0.49, 0.52.
Looking at your error screenshot, it confirms what’s happening: the embedding model is outputting 3072 dimensions but your table expects 768. So the model itself is definitely producing 3072-dim vectors regardless of what the n8n UI says the “default” should be. Your table at 3072 was actually correct for storage, the retrieval issue is probably a config mismatch somewhere in the agent setup. For text-embedding-005 if you want to try that route, Google’s docs say it outputs 768 dimensions by default so that should work with a 768 table, just make sure you use the same model for both store and retrieve.
