Embeddings & Vector Search

What is a vector store, and how does it work?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 14 min read

A vector store is a system that keeps embeddings, each with an id and optional metadata, and returns the stored items nearest to a query vector. Applications use a vector store to find text, images or products by meaning rather than by exact words. One rule decides which vectors can share a search: all must have the same length and come from the same embedding space, and the second step below shows the mixing error that rule prevents.

In this article

Before you start
Why interviewers ask this
Vector store from first principles
Worked example
Trade-offs and edge cases
How to answer it in an interview
Common mistakes
Follow-up questions
Sources

Before you start

This page is one step of the vector database and embeddings learning path, and it builds on the transformer models that produce embeddings.

Why interviewers ask this

A vector store is the layer that decides whether a search feature is fast, correct and easy to maintain, so an answer that stops at "it stores embeddings" misses the engineering. Interviewers use the topic to see whether you can separate three things: the embedding model that makes the vectors, the store that saves and searches them, and the index that makes the search fast.

A weak answer treats the store as a database for text and says search is always exact. A strong answer names the record (an id, a vector and metadata), says that vectors compared in one search share one dimension and one metric, and says that fast search is approximate and trades recall for speed. A Staff-level answer adds what breaks: changing the embedding model means re-embedding every item, filters interact with the index, and results change once an index is added. The topic fits any design that retrieves documents for a language model or recommends items.

Vector store from first principles

Vector store: A vector store is a system that saves embeddings together with an id and optional metadata and, given a query vector, returns the stored items with the highest similarity or the lowest distance. The term is general, covering a code library, an in-memory structure or a full vector database, and the same word names the interface that LangChain wraps around them.
Collection: A collection is a named set of stored vectors with ids and optional metadata that you search together. Each vector field in a collection has one fixed dimension and is compared with one distance metric.
Payload: A payload is the structured metadata attached to one stored vector, such as a color, a source document name or a date. It lets a search filter the results and lets the store return something useful alongside the id. The vector says what the item means; the payload says what else is known about it.

In plain words

Picture a huge wall map where every item you own is a pin. Pins for similar things sit close together. A search is a new pin for your question, and the store hands back the pins nearest to it.

The analogy breaks in two places. The map has hundreds or thousands of directions, not two. And the pins only make sense on the map drawn by one particular embedding model; pins placed by a different model sit on a different map, even when its size matches.

In one precise sentence, a vector store saves records made of an id, a vector and metadata, and answers a query vector with the stored records whose vectors are nearest under one distance metric.

Step 1: A record is an id, a vector and metadata

A stored record is an id, a vector and optional metadata. The id names the item, the vector says what it means, and the metadata says what else is known about it. Qdrant, a vector database, calls this record a point, and its documentation defines a point as a vector plus an id and a payload. Its points page shows one example with id 129, a four-number vector (0.1, 0.2, 0.3, 0.4) and the payload color red.

Input: an item and its embedding. Output: one record. Applications often keep the original text, or a reference to the file or row it came from, in the metadata, because a vector generally cannot be turned back into the item it stands for. You now know what one thing in the store looks like; the next step shows how records are grouped.

A collection is a named set of records that you search together. Qdrant's documentation states that the vector of each point in one collection must have the same dimensionality and be compared by a single metric, and that the metric is selected when the collection is created. Named vectors let one point carry several vectors, each with its own dimension and metric. In pgvector a column type such as vector(1536) fixes the dimension, while the metric is chosen by the query operator and by the index's operator class.

The reason is plain. A distance between a list of three numbers and a list of five is undefined. Two embedding models that output the same length still place items on different maps, so comparing their vectors gives meaningless closeness. The common error is mixing: putting vectors from two models, or compared by two metrics, into one vector field. Keep one vector field (or one collection) per embedding model and metric.

Input: a name, a dimension and a metric. Output: an empty collection ready for records. Changing the embedding model later therefore means a new collection or vector field and re-embedding every item.

Step 3: Adding a document embeds it and saves the record

In LangChain, the vector store interface is initialized with an embedding model, so the store embeds the text itself when you add it and saves the record. Its common operations are adding documents, deleting by id and similarity search. The query must land in the same vector space as the documents: usually the same embedding model, or a query encoder trained together with the document encoder, as in a two-tower model.

The base class reference describes the same methods: run more texts through the embeddings and add them, add or update documents, and delete by id or other criteria. Because many backends implement one interface, LangChain says you can switch implementations without altering application logic.

Input: text and metadata. Output: a saved record. LangChain's "vector store" is therefore an interface that holds an embedding model, not one product. For a concrete backend, see Qdrant as a vector database. Next comes the read path.

Step 4: A query is embedded, then compared with stored vectors

The application (or a wrapper such as LangChain) embeds the query into the documents' vector space, then the store scores it against the stored vectors by the collection's metric and returns the best few records, called the top k. The baseline is exact search, which compares the query with every stored vector. The pgvector README says it performs exact nearest neighbor search by default, which provides perfect recall.

The metric is usually Euclidean distance, dot product or cosine similarity. The Faiss README says similar vectors have the lowest L2 distance or the highest dot product, and that cosine similarity is a dot product on normalized vectors. In pgvector, sorting rows by the <-> operator against a query vector and keeping the first five returns the five nearest rows by Euclidean distance, and <#> and <=> give negative inner product and cosine distance (pgvector documentation mirror).

Input: question text. Output: a ranked list of records. How closeness maps to meaning is covered in semantic similarity.

Step 5: An approximate index trades some recall for speed

Approximate nearest neighbor search is a search that visits only part of the stored vectors, so it can miss a true neighbor in exchange for speed. Recall is the share of the true nearest neighbors that a search returns. Exact search has perfect recall, and an approximate index lowers it.

The pgvector README says you can add an index to use approximate search, which trades some recall for speed, and that you will see different results for queries after adding it. Hierarchical Navigable Small World (HNSW) is an index that builds a multilayer graph; Malkov and Yashunin describe a multi-layer structure of proximity graphs over nested subsets of the stored elements, searched from a sparse top layer downward. The ivfflat index divides vectors into lists and searches only the lists closest to the query. The page on vector indexing goes deeper.

You now have the whole system: records, a shared space and metric, and an index that trades recall for speed.

Each step adds one part of the store, and the index at the end trades some recall for speed.CC BY 4.0 — source: What is a vector store, and how does it work?

Step-by-step description

A record is an id, a vector and metadata.
Vectors compared together share one dimension and one metric.
Same space for documents and queries.
The query is compared with stored vectors.
An approximate index trades recall for speed.

A record is an id, a vector and optional metadata.
Vectors compared together share one dimension and one metric.
The query must land in the same vector space as the documents.
An approximate index trades some recall for speed.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

Four stored vectors and one query show why the metric matters. The query vector is (1, 2, 0) and the stored vectors are A (1, 2, 0), B (2, 4, 0), C (0, 1, 1) and D (-1, 0, 2), all illustrative.¹

The same query ranks the items A, C, B, D by distance, B, A, C, D by dot product, and gives A and B a tie at 1 by cosine, so the metric changes the answer.
Item	Vector	Euclidean distance	Dot product	Cosine similarity
A	1, 2, 0	0	5	1
B	2, 4, 0	2.2361	10	1
C	0, 1, 1	1.7321	2	0.6325
D	-1, 0, 2	3.4641	-1	-0.2

B points in exactly the same direction as the query but is twice as long, so the dot product rewards its length while cosine ignores it (illustrative).¹ After every vector is normalized to length one, the dot product equals the cosine, so a system can normalize once and then use the cheaper dot product.

Now size a collection. Raw storage is vectors times dimension times four bytes, because each number is a four-byte float. One million vectors of 1,536 numbers take 6.144 gigabytes raw, and an exact query does 1,536,000,000 multiply-adds, all illustrative sizes.¹ Indexes and metadata add more on top. Doubling the dimension doubles the raw size, as the chart shows for 384, 768, 1,536 and 3,072 numbers (illustrative).¹

Raw storage doubles whenever the vector length doubles, before any index or metadata is added.CC BY 4.0 — source: What is a vector store, and how does it work?

Text description of the diagram

Raw storage is vectors times dimension times four bytes.
One million vectors of 1,536 numbers take 6.144 gigabytes raw.

An ivfflat index shows how approximate search saves work. Suppose the million vectors sit in 1,000 lists of equal size and a query searches the 10 nearest lists. The store compares the query with 1,000 list centers and then with about 10,000 vectors, so 11,000 comparisons instead of 1,000,000, or 1.1% of the work (illustrative).¹ The saving has a price: a true neighbor sitting in a list that was not searched is missed, which is exactly the recall loss.

Trade-offs and edge cases

Exact search, hnsw and ivfflat trade recall, speed, build time and memory. The pgvector README says HNSW has better query performance than ivfflat in terms of the speed-recall trade-off, but slower build times and more memory. Exact search needs no index and returns perfect recall, but its cost grows with every vector stored.

Exact search is perfect but scans everything, while the two approximate indexes trade recall for speed in different ways.CC BY 4.0 — source: What is a vector store, and how does it work?

Text description of the diagram

Exact search gives perfect recall.
HNSW has better speed-recall performance than ivfflat but slower builds and more memory.

Edge cases that interviews probe:

Results change after indexing. An exact query and the same query after adding an approximate index can return different rows, so test recall on your own queries.
Dimension limits. The pgvector README states that indexing the vector type is limited to 2,000 dimensions (documentation mirror); check the limit of whichever store you use before choosing an embedding model.
Model changes. A new embedding model means a new collection or a new named vector field, and a full re-embedding, because old and new vectors live on different maps.
Filters. Filtering on metadata interacts with approximate search; see metadata filtering.
Meaning is not enough. Exact names and codes can be missed by vectors alone, which is why systems combine them with keyword search in hybrid search.