For each entry, it stores the vector (the embedding), the metadata (source, page number, tags, timestamps), and an index — a data structure that keeps similarity search fast even across millions of vectors. It also supports full CRUD: Create (add new vectors), Read (search/retrieve), Update (re-embed and replace a vector by id if the source changed), Delete (remove a vector by id if the document is gone).

• Cosine similarity — the angle between two vectors, ignoring magnitude. Most common for text embeddings, since most embedding models are trained to be compared this way.
• Dot product — similar to cosine but also factors in vector magnitude; slightly faster to compute, and equivalent to cosine once vectors are normalized to length 1 (which most embedding models do automatically — see Embeddings for the formula).
• Euclidean (L2) distance — straight-line distance between two points in space; more common for image/computer-vision embeddings, less common for text.

The metric isn't a free choice — it must match what the embedding model was trained and optimized against (documented per model), or similarity scores stop meaning what you think they mean.

Comparing a query against every single stored vector (brute-force / flat search) is accurate but doesn't scale. Vector databases instead use Approximate Nearest Neighbor (ANN) algorithms, trading a small amount of accuracy for a large speedup.

What is k-means clustering, in plain terms? It groups similar vectors into k clusters: place K centroids at random, assign every vector to its nearest centroid, recompute each centroid as the average of the vectors assigned to it, and repeat until the centroids stop moving much. A million vectors end up organized into, say, 100 meaningful clusters, so a search only has to check the few clusters near the query instead of everything.

HNSW builds a graph where each vector is a node, connected to a small set of nearby neighbors, organized into layers — sparse, long-range connections at the top layer for fast coarse navigation, dense, short-range connections at the bottom layer for fine-grained accuracy. A search enters at the top layer and greedily walks toward the query, dropping down a layer each time it can't get closer, until it reaches the bottom layer's most precise neighborhood. Three parameters control the accuracy/speed/memory trade-off directly:

• M — how many neighbor connections each node keeps. Higher M means better recall and more memory per vector.
• ef_construction — how thoroughly the graph is built at index time. Higher values build a better graph but take longer to index.
• ef_search — how many candidates are explored at query time. Higher values improve recall at the cost of query latency — this is the one knob you can safely tune per-query without rebuilding the index.

There's also LSH (Locality-Sensitive Hashing), an older ANN approach that hashes similar vectors into the same "bucket" with high probability, then only compares within matching buckets — largely superseded by HNSW in modern vector databases for text embeddings, but still relevant in some high-dimensional, memory-constrained settings.

Search results can be filtered by metadata before or alongside the similarity search — for example, only searching within documents tagged domain: "insurance".

Useful for multi-tenant systems (only search a specific customer's data), access control (only search documents the user is allowed to see), or simply narrowing the search space for efficiency and precision. Filtering can happen before the ANN search (pre-filter, exact but can be slow if the filter is very selective against a huge index) or after it (post-filter, fast but can under-return results if the top-k happens to contain few matches for the filter) — which strategy a database uses by default is worth checking, since it changes correctness under a narrow filter.

A single-node index eventually hits a ceiling on either memory (all vectors must typically stay resident for HNSW to be fast) or query throughput. Production vector databases address this the same way any distributed database does: sharding splits the vector collection across multiple nodes (each holding a subset of vectors, with a query fanning out to all shards and merging results), and replication duplicates the index across nodes for both read throughput and fault tolerance. This is invisible at small scale, but becomes the central operational concern once an index passes tens of millions of vectors or needs to serve high query-per-second traffic reliably.

Vector database cost scales primarily with two things: total vectors stored (drives memory/storage cost — HNSW indexes typically want to stay in RAM for full speed) and query volume (drives compute cost). A managed service bills for both directly; a self-hosted option shifts the cost to infrastructure and the engineering time to operate it. Dimension count and index parameters (like HNSW's M) both directly multiply memory usage, so the model and index choices made in Embeddings and above aren't independent of the cost of the database that stores them.