Vector Databases

A vector database receives embeddings from an encoding process and retrieves items near a query vector under a configured distance or similarity measure. It may provide approximate indexes, metadata filters, updates, persistence and distributed operations. Some products also offer lexical or hybrid search. The category includes embedded stores and managed or self-hosted services with different operational trade-offs. A vector database does not inherently know that a nearby item answers a question, and storing embeddings is distinct from training the model that produced them. Access control and consistency semantics depend on the implementation.

The practitioner compares candidate systems against realistic collection size, update rate, filtering needs and latency targets. It evaluates retrieval recall alongside memory, ingestion cost and operational reliability. Records should preserve embedding model version and source identity so incompatible representations are not silently mixed. Useful artifacts include the collection schema, index configuration, backup or recovery plan and relevance benchmark. Deletion and tenant isolation need end-to-end tests, especially where a retrieved vector maps to an external document with its own permissions.

Nearest neighbors can be irrelevant, and approximate search adds another source of misses. Aggressive filtering may change recall or leave too few candidates. Vendor features and limits evolve, so product selection needs current documentation and workload testing. A database is one stage of a retrieval system rather than a guarantee of answer correctness. Comparing exact search and a lexical baseline helps identify whether errors originate in indexing, representation or the evidence collection itself.