Vector database
A database that finds things by similar meaning instead of exact matching words.
A vector database stores embeddings: lists of numbers that an AI model produces to represent the meaning of a piece of text, an image or a sound. Things with similar meaning get similar numbers, so they end up close together, like points on a map. 'Puppy' lands near 'dog' and 'kitten', far from 'invoice'. A vector database is built to answer one question fast: which stored items are closest to this one?
That is different from a regular database search. Searching a help center for 'cannot log in' with plain keywords misses an article titled 'Resetting your password'. Searching by vectors finds it, because the meanings are close even though the words are different. To do this over millions of items without comparing against every single one, vector databases use special indexes (names like HNSW come up) that find nearly the closest matches very quickly, trading a tiny bit of precision for a lot of speed.
Vector databases became popular with large language models because they are the usual memory behind RAG: your documents are split into chunks, each chunk is embedded and stored, and when someone asks a question, the closest chunks are fetched and handed to the model as context. They also power semantic search, 'similar products' recommendations and duplicate detection. Some are dedicated products; others are features added to existing systems, like the pgvector extension for PostgreSQL.
Keep in mind
- Stores embeddings: numbers that represent meaning.
- Finds the nearest items to a query, not exact word matches.
- Uses approximate search to stay fast with millions of items.
- The usual storage behind RAG and semantic search.