Vector database

A vector database combines four components: durable storage of vectors with an ID and a payload of metadata (source text or reference, owner, date, access labels), one or more approximate nearest-neighbour indexes (most often HNSW, sometimes IVF variants or disk-based graphs such as DiskANN), a filtering engine for metadata predicates, and the usual database machinery of write-ahead logs, segments, replication and backup. The distance function (cosine, inner product or Euclidean) is fixed per collection or index and must match how the embedding model was trained. Vector quantization, whether int8 scalar, product or binary, reduces memory, usually with a rescoring pass over full-precision vectors for the top candidates. Sizing is simple arithmetic: one million 1,024-dimensional float32 vectors take about 4.1 GB before index overhead, and an HNSW graph adds link lists on top.

The market spans purpose-built systems (Milvus, Qdrant, Weaviate, Pinecone, Chroma and others), vector features added to general-purpose engines (the pgvector extension for PostgreSQL, which gained an HNSW index in version 0.5.0 in August 2023, and k-NN search in Elasticsearch and OpenSearch), and libraries such as FAISS and hnswlib. A library provides the index but not persistence, updates, filtering or access control, so it is not a database on its own. Pan, Wang and Li's 2024 survey in The VLDB Journal describes the design space. For many organisations, keeping vectors in an existing PostgreSQL or search cluster is simpler to secure, back up and govern than introducing a new datastore, at some cost in scale and features.

Filtering and freshness are the hard engineering parts. Combining a nearest-neighbour search with selective predicates such as "documents this user may read" risks returning too few results or skipping relevant ones, depending on whether filters are applied before, during or after the index traversal, and engines differ significantly here. Newly written vectors may be visible only after an index refresh, and deletions are often tombstones that are physically removed only at compaction.

Security and data protection follow from the fact that the store holds a copy, or a close derivative, of source content. OWASP's Top 10 for LLM Applications 2025 lists LLM08 Vector and Embedding Weaknesses, covering unauthorised access and cross-tenant leakage, embedding inversion and poisoning of the indexed data. Embeddings are not anonymous: Vec2Text (Morris et al., 2023) reconstructed 92 % of 32-token inputs exactly. Controls include mirroring source-system permissions as metadata and enforcing them in the query filter with the end user's identity, never only in the prompt; separate collections or namespaces for tenants with different trust levels; encryption and access logging; and, under the GDPR, including the store in the record of processing (Art. 30) and ensuring that erasure under Art. 17 reaches vectors, payloads, replicas and backups, not just the original document.