What is a vector database?

A vector database is a storage system built for one job: finding things that are similar in meaning, fast. It holds embeddings — long lists of numbers produced by AI models — along with the original content and metadata, and it answers queries like “which 5 document chunks are closest to this question?”

How it works

1. Ingest. Content is chunked, each chunk is turned into an embedding, and the vector plus the original text and metadata (source, date, author, permissions) is stored.
2. Index. The database builds special indexes (approximate nearest neighbour, or ANN) so it doesn’t have to compare your query against every single vector.
3. Query. Your question is embedded with the same model, and the database returns the nearest vectors — usually in milliseconds, even across millions of items.
4. Filter. Good systems combine similarity with metadata filters (“only documents this user may see”, “only 2026 policies”) and often with keyword search (“hybrid search”).

An analogy for the meatbags

A traditional database is a phone book: brilliant if you know the exact name. A vector database is a well-travelled friend: describe the vibe — “cosy Italian place, not too loud, good for a date” — and they’ll name the three closest matches, even if none of them uses those words on their sign.

Why it matters for the Chosen

Vector databases are a core component of retrieval-augmented generation, which is how businesses get AI to answer accurately from their own content. Common sellable builds:

• Support assistants that answer from help docs and past tickets.
• Internal search across Notion, Google Drive and Slack.
• Product recommendation and “similar items” features for ecommerce.
• Lead and content matching — pairing prospects with case studies, candidates with jobs.

You don’t always need to touch one directly. No-code platforms and AI tools often include a built-in vector store. But knowing what’s underneath helps you debug the classic failure: the chatbot answers confidently from the wrong document because retrieval pulled the wrong chunk.

Things to know

Retrieval quality depends more on chunking, embedding model choice, metadata and filtering than on which database brand you pick. Permissions matter — a vector store that ignores access controls will happily show the CEO’s salary memo to an intern. And when you change embedding models, you must re-embed your data. Keep this in mind as part of your LLMOps practice.