What is a vector database?

A vector database is a database that stores embeddings, the numeric vectors produced by machine learning models, together with IDs and metadata, and indexes them so it can quickly return the vectors closest to a query vector. It supplies what nearest neighbor search needs in production: durable storage, an approximate nearest neighbor index, updates and deletes, and filtering. The term covers both dedicated systems built only for vectors and general-purpose databases that support vector indexes.

​

What does a vector database store?

Each record typically combines an ID, a vector, metadata, and optionally the original content. The vector comes from an embedding model, typically run by the application before writing the record; some systems can call the model themselves. See What are vector embeddings? for how those vectors are produced.

​

What does a vector database do?

It keeps vectors searchable as data changes: it writes and indexes vectors, answers top-k similarity queries, filters results, and stores data durably.

• Writes. Inserts, updates, and deletes vectors while keeping the index current.
• Indexing. Builds an approximate nearest neighbor index, such as HNSW or IVF, so a query does not compare against every vector. See What is vector search?.
• Similarity queries. Takes a query vector and a number k and returns the k closest records it finds (approximately, when an ANN index is used), with their distances or scores.
• Filtering. Restricts results by metadata, such as a tenant or a date range.
• Durability and scale. Persists data, recovers from failures, and serves concurrent queries.

​

Do I need a vector database?

Not always. The answer depends on collection size, how often data changes, and where the source data already lives.

• Probably not for a small, static collection. A few thousand vectors held in memory can be searched exhaustively, and a prototype rarely needs more.
• Probably yes when exhaustive search no longer meets your latency budget, when vectors change often, or when you need filters, durability, and concurrent access.
• Maybe not a separate one if your existing database supports vector indexes. The next section compares the two options.

​

Should vectors live in a dedicated store or inside a general database?

It depends on how much retrieval relies on data that lives elsewhere. The two options differ mainly in where vectors sit relative to their source records. A separate store needs a pipeline that detects each change in the source data and copies the new vector or updated metadata into the store. Until the pipeline catches up, search can match stale content, return chunks of deleted documents, or honor revoked permissions. See this comparison for these costs in more detail.

​

Where does vector-only storage fall short?

A vector captures what a piece of content is about. It does not capture:

• Relationships. Which chunk came from which document, which ticket belongs to which customer, which document cites which.
• Ownership and permissions. Who may see a record, often derived from team or group membership.
• Recency and lifecycle. Which version is current, and what was superseded or deleted.
• Provenance. Where a fact came from and which source to cite.

Vector stores usually approximate these by copying fields into each vector’s metadata. That works for flat, stable attributes such as a tenant ID or a document type. It works poorly for facts derived from relationships that change, such as group membership, sharing, or version history: one change can require rewriting metadata on many vectors.

​

How does a vector database differ from a graph database or a search engine?

The three answer different questions, and many systems now combine two or more of them. See What is a graph database? and What is full-text search? for the other two.

​

How are vector databases used in RAG?

In retrieval-augmented generation (RAG), a retriever finds passages to include in a language model’s prompt, and vector search over a vector database is the usual retriever. Anything retrieved can appear in the answer, so the gaps described above, especially permissions, freshness, and provenance, matter more in RAG than in a search box. A production retriever also typically needs:

• Exact term matching for names and IDs, often through hybrid search.
• Related context, such as expanding a chunk to its document, author, or linked entities, as in GraphRAG.

​

How does HelixDB store vectors?

HelixDB is an open-source graph database with native vector search and BM25 full-text search. Vectors are stored as properties in the graph rather than in a separate store.

• An embedding is a property on a node or an edge, next to that entity’s other properties and relationships. The application computes embeddings; HelixDB stores and indexes them.
• A vector index covers one label and one top-level property, with a fixed dimension and a cosine, Euclidean, or Manhattan distance metric. Vector indexes can be partitioned by tenant.
• Each request is one ACID transaction. A write batch that creates a document, its embedding, and its edges commits or rolls back as a unit, and vector search runs in the same transaction as graph traversals.
• Relationships such as ownership and provenance can be modeled as edges, so a vector search can be restricted to an exact candidate set defined by a traversal.

See the data model, vector indexes, and prefiltered search.

​

Frequently asked questions

​

Is a vector database the same as a vector index?

No. A vector index is a data structure, such as HNSW or IVF, that speeds up nearest neighbor search. A vector database wraps one or more indexes with storage, updates, filtering, durability, and a query interface.

​

Can a vector database enforce permissions?

Per-record permissions usually come from filters, though many systems can also isolate data in separate collections or tenant partitions. Filters typically check metadata copied onto each vector, such as a tenant or group ID, so that copy has to change whenever access changes. The filter must also apply before or during ranking; filtering after ranking can return fewer than k results. See filtered vector search.

​

Does a vector database store the original text?

It can, but it does not have to. Storing the chunk text with the vector lets results go straight to the application or a language model. Storing only an ID keeps a single copy of the text in the source system, at the cost of an extra lookup per result.

​

What happens when the embedding model changes?

Vectors from different models, or different versions of one model, are not comparable. Every stored vector has to be recomputed with the new model, the index rebuilt, and queries embedded with the same model. See What are vector embeddings?.

​

Related topics