How it works
A normal database finds exact matches: every order from one customer, every post with one tag. It cannot find the paragraph that means roughly the same as a question worded differently. A vector database can. Each piece of content is stored with its embedding, and a search asks for the embeddings nearest to the query's embedding. Near means similar in meaning.
Comparing a query against every stored item is exact but slow once there are millions of items, so vector databases build an index that finds close matches quickly at the cost of occasionally missing one. They also store ordinary fields beside each vector, such as a title, a date or an owner, so that a search can be filtered: the nearest chunks, but only from this course.
Creators meet vector databases as the storage behind chat with your documents features, AI agent memory and search by meaning on a site. There are dedicated products, and there are extensions that add vector search to a database you may already use, such as pgvector for Postgres. For a small project the choice matters less than people expect. The quality of the chunks and embeddings you put in matters more.
A worked example
A creator has 300 blog posts and wants readers to search by meaning, not by exact words.
- Each post is split into sections, and each section is stored with its embedding, its title and its URL.
- A reader types: how do I stop my videos looking blurry. No post uses those exact words.
- The query is embedded and the database returns the five nearest sections, including one titled Upload quality settings.
- The site shows those posts. The match came from meaning, not from shared keywords.
An illustration, not a real account. Any numbers in it are made up to show the method, and are not benchmarks.
Common mistakes
- Reaching for one too early. A few hundred short documents can be searched with keywords or sent straight to the model.
- Changing the embedding model without re-embedding the content. Vectors from different models are not comparable.
- Thinking the database understands the text. It only compares numbers. The understanding, such as it is, comes from the embedding model.
Questions people ask
Is a vector database the same as a normal database?
No, though the line is blurring. A normal database is built for exact lookups and filters. A vector database is built for nearest-match search. Several ordinary databases now offer both.
Do I need a paid service?
Not to begin with. Open-source options exist, including pgvector, which adds vector search to Postgres.
How is a vector database used in RAG?
It is the lookup step. The question is embedded, the nearest chunks are fetched from the vector database, and those chunks are given to the model to answer from.
Sources
The project describes itself as open-source vector similarity search for Postgres, with exact and approximate nearest neighbor search.
Every link was opened on 13 October 2026. Products and policies change, so check the source before you rely on a figure.