How Vector Database works in practice
When text, images, or audio are passed through an embedding model, they are converted into arrays of hundreds or thousands of floating-point numbers (for example, 1,536 dimensions). Finding the closest vectors to a user query across millions of documents using brute-force exact comparison (`k-NN`) is too slow for real-time applications. Vector databases solve this using Approximate Nearest Neighbour (ANN) indexing algorithms, most commonly Hierarchical Navigable Small World (HNSW) graphs or Inverted File (IVF) indexes, which return top matches in milliseconds using cosine similarity, dot product, or Euclidean distance.
Modern production deployments fall into two camps: dedicated vector engines (such as Qdrant, Pinecone, Weaviate, and Milvus) built for massive scale and low-latency filtering, and vector extensions inside existing relational or search databases (most notably PostgreSQL with `pgvector` and `pgvectorscale`, Elasticsearch, and MongoDB Atlas).
For example, a UK property portal stores 12 million listing descriptions and floorplan embeddings in PostgreSQL using `pgvector`. When a buyer searches for 'bright Victorian terrace near a primary school with a south-facing garden', a single query applies strict SQL metadata filters on price, postcode, and bedroom count while ranking semantic vector similarity.
Why it matters and trade-offs
A vector database allows software to search by meaning rather than exact vocabulary, bridging the gap when a customer asks about 'cancelling my plan' and the policy document calls it 'contract termination'. Crucially, enterprise retrieval requires pre-filtering on metadata (tenant ID, user permissions, document date) during the index traversal itself; bolt-on post-filtering after vector search often returns zero results when a user only has access to a small slice of the corpus.
However, teams frequently over-complicate their stack by introducing a separate managed vector database when they only have 200,000 chunks. Below a few million vectors, `pgvector` inside an existing Postgres cluster avoids dual-write synchronisation bugs, keeps relational joins transactional, and reduces infrastructure sprawl.
