IBM Db2 Vector Store in n8n, following the existing vector store node pattern used by providers like PGVector and Pinecone.
Our use case:
We want to use IBM Db2 as the backend for AI workflows in n8n, particularly for:
Document embedding storage
Semantic search / vector retrieval
Retrieval-Augmented Generation (RAG) workflows
Enterprise use cases where structured business data and vector data should reside within the same database platform
Agent workflows where the vector store can be used as a retriever or tool
Db2 is especially relevant for enterprise teams already using it for operational workloads and governance. A native n8n node would simplify building AI workflows without requiring data movement to a separate vector-only platform.
The most useful initial step would be a Db2 Vector Store node with behavior similar to existing n8n vector store nodes, including:
Inserting documents with embeddings
Loading and retrieving documents
Metadata-aware retrieval (if supported)
Compatibility with retriever-based flows
Compatibility with tool / agent workflows
Potential future extensions could include:
Db2 Chat Memory support
A Db2 SQL node (as a separate node) if it aligns with n8n’s scope
Any resources to support this?
Recent ecosystem update:
IBM has recently introduced an official Db2 integration for LangChain:
This is an open-source Python connector that enables Db2 to function as a vector store within LangChain workflows, supporting use cases like RAG and AI agents. (IBM)
It allows developers to:
Store and manage vector embeddings directly in Db2
Perform semantic search and similarity queries
Build AI pipelines using Db2 as a native vector backend
Additionally, LangChain now provides a dedicated langchain-db2 integration package with support for vector storage, similarity search, and metadata filtering. (LangChain Docs)
This further reinforces that Db2 already aligns with the same architectural pattern used by existing n8n vector store providers.
Yes — we IBM team are willing to explore and contribute this, starting with a scoped initial implementation aligned with n8n’s existing vector store architecture.
Hey @DhruvChaturvediIBM , this is a solid feature request and the fact that the IBM team is willing to contribute makes it even more actionable.
Since you are open to building this, the fastest path is to follow how the PGVector node is structured in n8n’s source code. It is the closest match to what you are describing since it also handles document insertion, retrieval and RAG workflows inside a relational database. You can find it in the n8n repository under packages/nodes-langchain and use it as your reference implementation.
Since IBM already has an official LangChain integration through the langchain-db2 package, the heavy lifting on the vector logic is already done. Your node would mostly be a wrapper that connects n8n’s vector store interface to that package, similar to how other vector store nodes wrap their respective LangChain classes.
A few things to keep in mind before you start building:
Make sure you go through n8n’s contributing guide on GitHub so your implementation follows their code standards and review process from the start. This saves a lot of back and forth later.
Open a feature request or discussion on the n8n GitHub first if you have not already so the core team is aware and can give early feedback on the approach before you write too much code.
Start with just the core operations which are insert and retrieve. Get those reviewed and merged before adding metadata filtering or agent tool compatibility. Smaller scoped PRs move faster through review.
This is genuinely a useful addition for enterprise users and the LangChain connector existing already makes the case for it much stronger. Good luck with it.
The structured approach is solid — PGVector as reference is the right call. One thing that could accelerate adoption: since IBM already has the LangChain connector, publishing that connector docs alongside the initial node would help enterprise teams understand Db2’s capability in context of their existing AI workflows. The vector store pattern n8n uses is clean, and Db2 fitting that pattern makes sense for enterprise consolidation.
We noticed that the feature request redirects to the community page. Could you please advise if there is another process available for submitting feature requests?
Hey @DhruvChaturvediIBM, The community forum is actually the intended starting point for feature requests in n8n that is by design, not a gap in the process.
That said, since you are planning to contribute the node yourselves rather than just requesting it, the more relevant path is to open a GitHub issue directly in the n8n repository:
Use the Feature Request issue template and describe the IBM Db2 Vector Store node scope. This puts it on the core team’s radar officially, allows them to comment on the approach before you write code, and gives your PR a linked issue to reference when you submit it.
The community post is still valuable for gauging interest from other users, but the GitHub issue is what the engineering team tracks and responds to. Doing both is the strongest approach community post for visibility, GitHub issue for the technical discussion and formal acknowledgment from the maintainers.