Vector database

A vector database holds millions of embeddings and, given a query vector, returns the closest ones in milliseconds. It does this with approximate nearest-neighbour indexes such as HNSW or IVF, which trade a little exactness for large speed gains. Alongside each vector it stores metadata (tenant, document ID, date, access group) so results can be filtered before or after the similarity search.

Options range from dedicated products (Pinecone, Qdrant, Weaviate, Milvus) to extensions in databases you already run, chiefly pgvector in PostgreSQL. Most search engines, including OpenSearch and Elasticsearch, also support vectors now, which makes hybrid search simpler.

A vector database is not a knowledge base and not a RAG system; it is the index layer. It does not decide what to chunk, how to rerank or who may see what. Teams often over-invest here early; for corpora under a few million vectors, the choice matters far less than chunking and retrieval quality.

• CTO / Head of Engineering: Whether to add a new managed service or use pgvector in the Postgres you already operate is an architecture and ops decision with a long tail.
• CISO: A managed vector service is another place your document content lives; residency and data-egress rules apply to it.
• CFO: Managed vector databases bill by storage and throughput; for moderate corpora this is often a cost you do not need to add.
• Data lead: Metadata filtering and tenant scoping in the index are what keep retrieval both fast and correctly bounded.

Ordinary databases index exact values; they cannot answer "find the ten records most similar to this one" across millions of high-dimensional vectors without scanning everything. Vector databases exist to make that query fast enough for interactive use. The trade-off is approximation and operational surface: ANN indexes can miss the true nearest result, indexes need rebuilding as data changes, and a separate store must be kept in sync with the system of record. For many products a vector extension in the existing database avoids the sync problem entirely.

• Knowledge-base retrieval for a multi-tenant SaaS copilot with tenant ID as a hard filter on every query
• Similar-transaction and similar-case lookup in a FinTech fraud review tool
• Product similarity and "more like this" for a retail catalogue with in-stock and region filters
• Retrieval over patient-education material for a hospital assistant hosted inside the hospital's VPC
• Semantic search across shipment notes and exception logs in a logistics dispatch platform

Tool / technologyA category of software you select and operate rather than a skill in itself. Eazyware benchmarks pgvector against managed options on the client's own corpus as part of Retrieval & Knowledge Engineering engagements.

Eazyware service that covers it: Retrieval & Knowledge Engineering. Starting prices are on the pricing page.