Vector Database
Also called: vector store, embedding database
A store for embeddings that finds text by meaning rather than by keyword — and for most workloads, a Postgres extension rather than a separate product.
Text is converted into a list of numbers — an embedding — that positions it in a space where similar meanings sit close together. A vector store holds those embeddings and answers "what is nearest to this".
That is what lets a search for "can I get my money back" find a passage titled "refund eligibility", which keyword search would miss.
Do you need a dedicated one?
Usually not. Under a few million chunks, pgvector alongside your relational data in
Postgres is simpler, cheaper, and — the part people underrate — keeps your embeddings
and your source records in the same database, so they cannot drift apart.
Dedicated vector databases earn their operational cost at higher scale, with specialised filtering needs, or where a very high query rate justifies purpose-built indexing.
The two design decisions that actually matter
Hybrid search. Pure vector similarity misses exact matches — product codes, error strings, names. Combining keyword and vector search, then reranking, is what takes retrieval from demo-quality to production-quality.
Source lineage. Every stored chunk should carry the source system and record id it came from. Without it you cannot apply per-user permission filters at query time, and you cannot honour a deletion request — which under the DPDP Act means a full reindex. It costs nothing at design time.
Where teams go wrong
Treating the store as the hard part. The store is the easy part. Chunking strategy, what metadata you attach, whether you rerank, and how you enforce permissions are the consequential decisions — and the only way to know if you got them right is an evaluation set.