Vector databases
A vector database stores your text chunks together with their vector, the numeric fingerprint of their meaning. When searching, it turns the question into another vector and returns the chunks whose vectors are closest. It is the central piece of almost any RAG.
In NappAI you find them in the Vector Stores category of the palette. They all work the same way: an Operation field decides whether they store, search, or act as a retriever for another component.
The conclusion first: quality is the same
We measured FAISS, Chroma, Qdrant and PGVector with the same 80 chunks, the same vector model and the same 40 questions. All four returned exactly the same first five results for all 40 questions. With the same information and the same vector model, the database does not change what you find: choose by how you work, not by quality.
| Database | Answer in the first result | Among the first five | Storing 80 chunks (with their vectors) | Time per search in a flow |
|---|---|---|---|---|
| FAISS | 60 % | 83 % | 10.0 s | 16 ms |
| Chroma DB | 60 % | 83 % | 12.7 s | 16 ms |
| Qdrant | 60 % | 83 % | 12.3 s | 36 ms |
| PGVector | 60 % | 83 % | 12.8 s | 35 ms |
| Neo4j (with Neo4j GraphRAG, Vector mode) | 60 % | 83 % | – | 44 ms |
Measured on 17 October 2026 on a laptop, with a test knowledge base of 9 documents and 40 questions. It shows how they behave; it is not a promise for your data. In Neo4j, vector search is approximate: asked for only 5 results, it sometimes does not return the 5 closest ones. That is why Neo4j GraphRAG always asks for at least 50 candidates and keeps the ones you ask for; measured that way, its first five results match FAISS’s on every question. More details in How we measured it.
What each one offers
| FAISS | Chroma DB | Qdrant | PGVector | Neo4j (Neo4j GraphRAG) | |
|---|---|---|---|---|---|
| Needs a server | No | No (or your Chroma server, if you have one) | Yes | Yes: PostgreSQL with the vector extension | Yes |
| Where it is stored | Files in your NappAI storage | A folder in your NappAI storage, or your server | Your Qdrant server | Your database | Your Neo4j database |
| Filters on chunk data | Yes (Filter by Metadata); an agent can fill them in | Yes, without Contains or lists | Yes; an agent can fill them in | Yes; an agent can fill them in | Yes: Filter by Metadata on the Neo4j component, or written in Retrieval Query |
| Score threshold | Yes | Yes | Yes | No | No |
| Diverse results (MMR) | No | No | Yes | No | No |
| Keyword and meaning search | With BM25 Retriever + Ensemble Retriever | Same as FAISS | Same as FAISS | No | Yes, built in (Hybrid modes) |
| Following relationships (graph) | No | No | No | No | Yes |
| Filters written by a model (SelfQueryRetriever) | No | Yes | Yes | Yes | No: use Text2Cypher mode |
Which one to choose
| Your situation | Choose | Why |
|---|---|---|
| You want to try RAG today, without installing anything | FAISS | No server: the index is kept in your NappAI storage, and another flow in your account reads it with the same Index Name and Persist Directory. |
| An FAQ or medium-sized manuals, and you want to filter by category | Chroma DB | No server either, it supports filters and it works with SelfQueryRetriever. |
| Many documents, several flows or agents querying the same collection | Qdrant | A server built to grow, and the only one of the four with filters, threshold, MMR and SelfQueryRetriever together. |
| Your company already runs PostgreSQL | PGVector | The vectors live in a table of your usual database, with its backups and permissions. The component has no filters. |
| Your data are customers, machines, orders or people linked to each other | Neo4j with Neo4j GraphRAG | Besides searching by meaning, it follows relationships and answers counting questions. See GraphRAG with Neo4j. |
To store text chunks in Neo4j there is also the Neo4j component in Vector Stores, with the same operations as the other databases.
Other vector databases in the palette
If your company already uses one of these services, you can store and search in it with the same operations:
- Astra DB: DataStax’s cloud vector database.
- Cassandra: on your Apache Cassandra database.
- Couchbase: on your Couchbase database.
- Elasticsearch: if your data is already in Elasticsearch.
- Milvus: an open-source vector database for large volumes.
- MongoDB Vector Store: on MongoDB Atlas.
- Pinecone: a managed cloud vector search service.
- Redis: on your Redis server.
- Supabase Vector Store: on your Supabase project.
- Upstash: a pay-per-use cloud vector database.
- Vectara and Vectara RAG: search and, in the second one, a full answer inside Vectara.
- Weaviate Cloud (v4): on Weaviate Cloud, with several filters.
The three operations
Every database has the Operation field, and each value shows its own fields and outputs:
| Operation | What it does | What you connect | Output you use |
|---|---|---|---|
| Add | Stores the chunks arriving at Ingest Data, with their vectors. | A text splitter or Metadata Tagger to Ingest Data, and a vector model to Embedding. | Vector Store, for components that read the whole database, such as BM25 Retriever. |
| Search | Searches for what you write or connect in Search Query and returns the chunks. | The question to Search Query. | Results: the chunks, for a prompt, another component or an agent that uses the database as a tool. |
| Retriever | Does not search by itself: it hands a retriever to another component, which uses it with its own question. | Only the vector model. | Retriever: for Local Rerank, Ensemble Retriever, Multi Query Retriever, the RAG Agent or RetrieverTool. |
This is how the usual pieces connect:
- Agent that searches your documents, with reranking. Database in Retriever → Retriever of Local Rerank → Tool output of Local Rerank → Tools of the Agent. The agent writes the question and gets the best chunks.
- Agent that searches without reranking. Database in Search → Tool output → Tools of the Agent.
- Specialised RAG agent. Database in Retriever → Retrievers of the RAG Agent. You can connect several databases.
- Direct results for a prompt. Database in Search with the question in Search Query → Results → your prompt or component.
Number of Results decides how many chunks the database returns. If you rerank afterwards, ask for more than you want to keep, for example 12 or 20, and let Local Rerank keep 4 or 5.
Next step
Before storing anything, decide how to chunk and prepare your documents: Vectorising and tagging.