Vector Database
A vector database is a storage system that stores texts, images, or sounds as long sequences of numbers and searches within them by similarity rather than by exact words. It is the foundation that allows AI assistants to find matching passages in large document collections.
An ordinary database searches for exact matches. You search for the name “Miller,” and you get all entries in which exactly that word appears. A vector database works differently: it searches for content-based similarity. To do this, every stored piece of content is first translated into a long sequence of numbers, often several hundred numbers long. This sequence of numbers is called a vector, and it describes the meaning of the content. Similar content receives similar sequences of numbers, even if they don’t share a single word.
Why searching by meaning finds more than searching by words
Classic search fails because of language. Someone who types “car broken” won’t find a text about “vehicle damage.” A human immediately sees that both mean the same thing. A search based on exact character strings does not see this. A vector database, on the other hand, places both phrasings close together and returns them together.
This became especially important with language models like ChatGPT. These models only know what appeared in their training. They know nothing about internal company documents, current prices, or your own textbook. However, you can supply them with the relevant text passages before asking the question. This method is called Retrieval Augmented Generation, or RAG for short. The vector database is the component that finds the matching passages.
The effect is tangible: the model makes things up less often. Instead of guessing, it formulates an answer from texts that actually exist. You can even display the source alongside it. That’s why almost every corporate chatbot today has a vector database built in.
From sequences of numbers to neighbors in space
At the start there is a dedicated AI model, the embedding model. It receives a text passage and outputs a vector for it. You can imagine this as coordinates in a space. On a map, two numbers are enough for a location. Here, there are 384, 768, or more, because meaning has many facets. Texts with similar content end up at neighboring points.
A search query is passed through the same model and likewise becomes a point. The database then searches for the nearest points. The distance between two vectors is a measure of content-based closeness. What comes back are typically the five or ten nearest neighbors.
Calculating all distances individually would be too slow with millions of entries. That’s why vector databases build an index, usually using a method called HNSW. It creates a network of connections between similar points, through which the search feels its way forward. The result is not guaranteed to be exact, only very likely correct. This small loss of accuracy is accepted because it makes the search take milliseconds instead of seconds.
Which products are built on this
In everyday life, you don’t notice the technology, but you use it constantly. The photo search on a smartphone finds “dog on the beach” without anyone having labeled the images. Music services suggest similarly sounding tracks. Online shops display comparable products. Behind each of these lies the same idea: similarity between sequences of numbers.
The names of providers show up in the business press. Pinecone, Weaviate, Qdrant, Chroma, and Milvus are specialized systems. At the same time, established databases like PostgreSQL have retrofitted this function with the pgvector extension. This is exactly what is being debated: do you need a dedicated product, or is vector search just an add-on feature of existing databases?
One common misconception should be cleared up: a vector database is not an AI model and understands nothing. It only stores and compares numbers. The understanding lies in the embedding model that generated the numbers. If that model is poor, even the fastest database won’t help.
