Skip to content
KNIME Documentation
Main Navigation Get startedBuildWork with KnimeAccount and adminRelease notesDeveloper tools
Community Hub
DevelopersKnime 2.0
Sidebar Navigation

Getting Started

Installation

User Guide

Release Notes

Install Extensions

Building Workflows

Components

Flow Control

Expressions

File Handling

Deployment

Integrated Deployment

Workflow Invocation

Best Practices

Advanced Features

AI Extension

Get Started

Build an Agent

Inject context with RAG

LLM Providers

Tutorials

Summarize product reviews

Product FAQ assistant

Restaurant agent

Your first local agent

Task extractor

Reporting

Kerberos

Extensions

Database

Python

R

Deep Learning

Snowflake

Google Cloud

Azure

AWS

Big Data

Big Data Admin

Big Data Secured Cluster

Databricks

Microsoft Fabric

Power BI

Tableau

Report Designer

H2O

Changelogs

Version 5.11

Version 5.10

Version 5.9

Version 5.8

Version 5.7

Version 5.6

Version 5.5

Version 5.3

Extensions

Outdated version

This is the documentation for KNIME Analytics Platform version 5.11 - go to the latest version.

Create a vector store ​

Store embeddings in a vector index so they can be efficiently retrieved using semantic similarity.

A vector store maps documents to numerical vectors and enables similarity-based search, which is the foundation of retrieval-augmented generation (RAG).

When this is useful ​

Create a vector store when you want to:

  • Reuse embeddings across workflows
  • Perform semantic search over documents
  • Retrieve relevant context for RAG workflows
  • Persist embeddings for repeated or scheduled use

If you only need embeddings for immediate, in-memory processing, see Create embeddings instead.

Choose a vector store backend ​

KNIME supports multiple vector store backends.

The most commonly used are:

  • FAISS – a flat-file–based index optimized for fast, local similarity search
  • Chroma – a JSON + SQLite–based store with support for metadata and collections

Choose the backend that best fits how you plan to store, reuse, and filter your data.

Which backend should I use?

Use FAISS for lightweight, local vector search with minimal overhead. Use Chroma if you need metadata, document grouping, or more advanced filtering.

Create a vector store ​

Prerequisites
  • Embeddings available in a table column
  • A provider and credentials configured (see Providers)

Create a FAISS vector store ​

Use the FAISS Vector Store Creator node to generate a FAISS index.

You can either:

  • generate embeddings inside the node using an embedding model, or
  • provide a column containing precomputed embeddings

The node produces a vector store that can be reused for similarity search and retrieval tasks.

Create a Chroma vector store ​

Use the Chroma Vector Store Creator node to create a Chroma-based vector store.

In addition to embeddings, Chroma supports:

  • metadata columns
  • document collections
  • filtering during retrieval

Like FAISS, Chroma can work with either inline or precomputed embeddings.

Reuse a vector store ​

To persist a vector store and reuse it across workflows (including executions on KNIME Hub), store it as a KNIME model object.

Save the vector store ​

Use the Model Writer node to save the vector store to the workflow data area or directly on Hub. This makes the vector store portable and Hub-compatible.

Reload the vector store ​

Use the Model Reader node to load the saved vector store in another workflow. This reliably enables sharing and reuse in scheduled Hub executions.

Vector store readers

Backend-specific nodes such as:

  • FAISS Vector Store Reader
  • Chroma Vector Store Reader

require explicit filesystem paths. On KNIME Hub, workflows do not expose a traditional local filesystem, so prefer Model Writer/Reader for cross-workflow persistence.

The FAISS and Chroma reader nodes are also useful when the vector store was created by an external tool (e.g., in Python) and you want to load it into KNIME for retrieval.

Result ​

You obtain a reusable vector store that contains:

  • embeddings
  • optional metadata (backend-dependent)
  • an index optimized for similarity search

Use it to retrieve relevant documents based on semantic similarity.

Next steps ​

  • Retrieve relevant documents: see Retrieve context
  • Inject retrieved context into prompts: see Inject context into a prompt
  • Build a complete RAG workflow: try the Product FAQ Assistant tutorial
Pager
Next pageInstallation