Vector Database
A database that stores text as numeric vectors so you can search by meaning instead of exact keywords, which is the retrieval engine most RAG systems run on.
A vector database stores embeddings: numeric representations of text (or images, or audio) where similar meaning maps to nearby points in space. Instead of matching exact keywords, you embed the user’s query the same way and ask the database for the closest vectors. That is similarity search, and it is what lets a system find “how do I cancel my plan” when the document actually says “subscription termination procedure.”
In a RAG pipeline this is the retrieval layer. The quality of your answers depends heavily on it: good embeddings and good search return the right chunks to feed the model, bad ones feed garbage and the model confidently summarizes garbage. This is why retrieval, not the model, is usually where RAG projects succeed or fail.
Here is the part vendors skip: you often do not need a dedicated vector database. If your corpus is small (thousands, not millions of chunks), a vector extension on the Postgres you already run (pgvector) is simpler, cheaper, and one less system to operate. If your search is mostly keyword-driven, plain full-text search may beat vector search outright. Reach for a specialized vector DB when scale, latency, or hybrid search at high volume actually justify it, not because it is on the architecture diagram.
We pick the boring-enough option deliberately under Artificial Intelligence, because every extra system is an extra thing to keep alive at 3am.