n8n Vector Store Workflows: Pinecone, Weaviate, and pgvector

A vector store gives a workflow a place to look for related information. The store does not replace a normal database. It adds a similarity search step for text, images, or other embedded data.

What is the basic workflow?

A useful n8n vector workflow has two paths. The first path ingests source material. It splits documents into chunks, creates embeddings, and saves the chunks with metadata. The second path receives a question, creates a query embedding, and retrieves nearby chunks.

Keep these paths separate when possible. Ingestion changes when the source changes. Retrieval changes when the user question or answer policy changes. Separate paths are easier to test and re-run.

When does a managed vector store help?

Pinecone and Weaviate can reduce infrastructure work. The service handles storage and search operations for you. This can be useful when a small team needs a working retrieval layer without maintaining another database service.

The trade-off is operational dependence. Check the service plan, region, index model, metadata limits, and backup options before production use. A managed service is still part of your data boundary.

When does pgvector make sense?

pgvector keeps embeddings beside relational data in PostgreSQL. It is a natural fit when the workflow already depends on PostgreSQL and needs joins between documents, users, permissions, or business records.

The trade-off is maintenance. The team must manage database capacity, indexes, backups, and upgrades. A clear capacity plan matters more than the choice of a fashionable tool.

Which metadata should you keep?

Store metadata that helps retrieval stay precise. Common fields include source ID, document type, tenant, language, created date, and access scope. Do not rely on the vector alone to enforce permission rules.

Filter by access scope before returning context to a model. The vector search finds related text. Your workflow still has to decide whether the current user may see it.

How should chunking be tested?

Small chunks can lose context. Large chunks can bury the useful sentence among unrelated text. Start with a bounded chunk size, then compare retrieval results with real questions.

Record the source chunk, the query, the score, and the final answer during testing. This gives you a trail when a result feels plausible but is wrong.

You can review the wider n8n integration-node catalog before connecting a store. The n8n architecture guide helps place retrieval inside a larger execution design.

A practical decision rule

Choose a managed store when speed and low maintenance matter most. Choose pgvector when relational joins, local control, or an existing PostgreSQL operating model matter most. In both cases, define chunking, metadata, access checks, update rules, and failure handling before measuring answer quality.

For current n8n AI and vector-store behavior, consult the official n8n AI documentation.