Vector Database
A vector database is a database that stores, indexes and searches for similarities in numerical representations of data – known as embeddings. This makes it possible to find content that is semantically similar, even if it uses different terms or phrasing.
Vector databases are primarily used where large volumes of unstructured data, such as text, images or audio files, need to be searched for similarities in content. Typical areas of application include semantic search, recommendation systems and Retrieval-Augmented Generation (RAG).
Key facts about vector databases at a glance
- A vector database stores and searches embeddings.
- It finds content based on semantic similarity rather than just keywords.
- Key areas of application include RAG, semantic search and recommendation systems.
- Techniques such as ANN and HNSW enable fast similarity searches across large datasets.
- A separate vector database is not always necessary. PostgreSQL with pgvector or systems with integrated vector search may also suffice.
- The right solution depends on data volume, performance, hosting, costs and operational overhead.
What is a vector database?
A vector database is a database system designed for storing and searching vectors. These vectors consist of numerical values and represent, for example, text, images, audio files or products. The key difference from a traditional database lies in the nature of the queries. A vector database searches for proximity within a mathematical vector space. This enables it to recognise content as similar, even when different terms are used.
What are embeddings?
Embeddings are numerical representations of content. An embedding model, for example, converts a text into a long sequence of numbers. Content with similar meanings is then positioned relatively close to one another within the vector space. The vector database does not usually generate this meaning itself. It stores the generated embeddings, indexes them and makes them efficiently searchable. In addition, metadata such as category, source, language, date or access rights is often stored. This allows semantic similarity to be combined with traditional filters.
A simple example of a vector search
Suppose a knowledge base contains a section with the sentence ‘The cancellation period is 14 days’. If a user searches for ‘How long do I have to return my order?’, the words used only partially match. Nevertheless, a suitable embedding model can still represent both pieces of content as semantically similar.
To achieve this, the query and the stored content are represented as vectors. The vector database compares their positions in the vector space and returns the content whose vectors are particularly similar to the query. In this way, a search can deliver relevant results without relying on identical keywords.
How does a vector database work?
- First, the source data is converted into embeddings. In the case of longer documents, the content is often broken down into smaller sections, known as ‘chunks’.
- The vector database then stores and indexes these vectors. For large volumes of data, methods such as Approximate Nearest Neighbour Search (ANN) and index structures such as HNSW are used. These prevent the need to compare every stored vector in full for every search query.
- The user’s query is also converted into an embedding. The database then searches for vectors with the highest possible similarity. Cosine similarity or Euclidean distance, for example, can be used for this calculation.
The result is not a simple keyword match, but an assessment of semantic proximity. In real-world applications, vector search is often combined with keyword search or metadata filters. This hybrid search is important, for example, when product numbers, proper names or exact technical terms need to be taken into account. Vector search does not replace keyword search; rather, it extends the search logic.
What are vector databases used for?
With RAG, the system first retrieves relevant information from a knowledge base and then passes it on to a large language model as context. A vector database can form the semantic retrieval layer in this process.
Users can search for meanings rather than exact phrases. This is particularly helpful for natural or vague search queries.
Products, content or user profiles can be represented as vectors. This enables systems to identify similar content or make appropriate recommendations.
Images, audio content and other media can also be represented as vectors and searched for similarities.
Why are vector databases important for RAG?
Large Language Models do not automatically have access to internal documents, up-to-date product information or specific company knowledge. RAG therefore supplements the model with a retrieval process.
A user’s query is converted into an embedding and compared with the stored documents. The most relevant text excerpts are then passed to the language model as context.
What a vector database is not A vector database fulfils a clearly defined purpose: it stores and indexes vectors and enables them to be searched efficiently based on similarity. However, it does not automatically handle all the other components of an AI application.
A vector database does not itself generate texts, answers or summaries. In applications such as RAG, it provides relevant information, whilst the actual text generation is carried out, for example, by a large language model.
The semantic vectors are usually generated by a separate embedding model. The vector database stores and indexes these vectors, and subsequently makes them searchable.
Vector databases specialise in similarity searches. Relational databases and other traditional database systems remain relevant for transactions, structured data, precise filtering and many other tasks. In practice, therefore, the two approaches are often combined.
The quality of a RAG system does not depend solely on the vector database used. The quality of the source data, the embedding model used, the division of documents into chunks and the retrieval logic also influence the results.
Vector database vs. traditional database
Criterion | Traditional Database | Vector Database |
|---|---|---|
Search | exact values, filters, IDs | Similarity |
Data | Tables, Documents, Fields | Embeddings and Metadata |
Typical Query | SQL, Keyword, Filter | Nearest Neighbor Search |
Strength | structured data | semantic relationships |
Typical AI Role | Data Source | Retrieval Layer |
In practice, the two approaches often complement one another. Product, customer or master data can continue to be stored in a traditional database, whilst embeddings are processed additionally to enable semantic search.
A vector database therefore does not usually replace existing databases, but rather complements them
What is the difference between a vector store and a vector database?
The terms ‘vector database’ and ‘vector store’ are often used interchangeably.
- A vector store is primarily used to store embeddings and retrieve similar vectors.
- A vector database, on the other hand, usually offers additional features such as indexing, metadata filters, scalability or hybrid search.
The distinction is, however, blurred: many vector stores now offer database functions, whilst traditional databases such as PostgreSQL, with pgvector, also support vector search. The specific use case is therefore more important than the label itself.
When is it advisable to use a separate vector database?
Not every application that uses vector search requires a standalone vector database system. Some traditional databases and search systems now also support the storage and searching of vectors. A well-known example is PostgreSQL in conjunction with the pgvector extension.
A specialised vector database can be particularly useful when very large volumes of embeddings need to be searched, when low response times are required, or when similarity search is a core function of an application. Specialised systems often offer features such as optimised vector indexes, metadata filters, distributed processing or hybrid search.
For smaller data sets or existing database environments, however, an integrated vector search function may suffice. Whether a separate vector database is required therefore depends on the technical requirements and the existing system architecture.
What vector database solutions are available?
| Solution | Type | Hosting | Best Fit | Advantage | Advantage |
|---|---|---|---|---|---|
pgvector | PostgreSQL extension | Self-hosted / Managed | Existing PostgreSQL stack | Minimal additional infrastructure | Vector search becomes a core function at very large scale |
Pinecone | Dedicated / Managed | Cloud | Minimal operational overhead | Managed vector search | Maximum infrastructure control is required |
Qdrant | Dedicated | Cloud / Self-hosted | Filtering, flexible deployments | Strong focus on vector search | An existing database already covers all requirements |
Weaviate | Dedicated / AI Search | Cloud / Self-hosted | Hybrid search / AI search | Comprehensive search model | A minimal architecture is preferred |
Milvus | Dedicated / Open Source | Self-hosted / Managed | Large-scale vector workloads | Scalability | low surgical complexity is a priority |
The name alone therefore provides only limited information about a system’s range of functions. What is crucial is what capabilities the respective solution offers in terms of vector search, indexing, filtering and scaling.
How do vector databases differ?
Vector databases can differ significantly in terms of their technical design and range of functions. The most important factors here are the type of indexing, the processing of large volumes of data, and additional search, filter and integration functions.
The most important differences include:
- Indexing: Systems use different methods to organise vectors efficiently and speed up similarity searches.
- Scalability: Depending on their architecture, solutions may be suitable for smaller datasets or for very large volumes of embeddings.
- Metadata filters: In addition to semantic similarity, results can be filtered by, for example, language, category, date, access rights or client.
- Hybrid search: Some systems combine vector search with traditional search methods such as keyword search. This is particularly useful when both semantic relationships and exact terms, proper nouns or product numbers need to be taken into account.
- Operating model: Some vector databases are offered exclusively as a managed service, whilst others can be operated in-house or integrated into existing infrastructure.
- Integration Options: Differences also lie in how easily a system can be connected to existing databases, applications, AI models or cloud services.
Which of these features are particularly important depends on the specific use case. Different requirements may apply to a simple semantic search than to large RAG systems or applications with high query volumes.
Conclusion: Vector databases enable similarity searches using embeddings
A vector database stores and indexes embeddings, enabling data to be searched based on its mathematical or semantic similarity. This means that vector search differs fundamentally from queries that rely exclusively on exact values or identical terms.
Typical areas of application include semantic search systems, retrieval-augmented generation, recommendation systems, and similarity search in texts, images and other unstructured data.
A vector database does not, however, fundamentally replace traditional databases. In many applications, structured data storage, traditional search methods and vector search complement one another. Whether a specialised database system or an existing platform with a vector search function is used depends on the specific technical use case.
Frequently Asked Questions about Vector Databases
A vector database stores numerical representations of data and can find similar content based on their mathematical proximity. This allows for searches based on meaning rather than just exact keywords.
A vector database can help RAG identify relevant document sections related to a user's query and provide them as context for a large language model. It is often useful for this purpose, but not strictly necessary.
For many small and medium-sized applications, PostgreSQL with pgvector may be sufficient, especially if PostgreSQL is already in use. For very large or specialized vector workloads, dedicated systems may offer advantages.
No. Vector databases specialize in similarity searches. Traditional relational databases remain important for structured data, transactions, and exact queries.
That depends on the specific use case. Key factors include data volume, performance, filtering options, deployment, data protection, costs, and existing infrastructure.
