Vector databases

Store embeddings, lists of numbers that capture what text, images or users mean, and find the ones closest to a query.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingNew documents and incoming questions go through the same embedding model. Documents are added to the vector index; each question becomes a vector, and the index walks its HNSW graph to the nearest neighbours that pass the filter and sends their ids back.

How it works

An embedding model turns each item (a paragraph, an image, a product) into a vector: a fixed-length list of floats placed so that similar items land close together. The database stores each vector with an id, the original document and metadata. A query is embedded with the same model, and the database returns the k nearest vectors by a distance metric: Euclidean (L2) distance, inner product, or cosine distance, which compares only the angle. Comparing the query with every vector gives exact results but reads everything, and classic tree indexes stop helping above about 10 dimensions, so large collections use approximate nearest neighbour (ANN) indexes that trade a little recall for speed. An inverted file (IVF) index clusters the vectors around centroids at build time; a query looks only at the few clusters whose centroids are nearest (the probes or nprobe setting). HNSW builds a layered graph: sparse upper layers act as highways, and a search starts at the top layer and works down to the query’s neighbourhood, with a candidate list size (ef_search) setting how hard it looks. Filters on metadata such as language or tenant are applied before the vector search (exact search over a small subset) or after it, in which case an approximate index may return fewer than k matches. Dedicated vector databases do this, but so do PostgreSQL with the pgvector extension and search engines such as Elasticsearch and OpenSearch, next to the rest of your data.

Think of it as

A wine shop arranged by taste instead of by label. Similar wines stand next to each other, so to find something like the bottle you liked you walk to its shelf and look around, instead of reading every label in the shop. An approximate index is the floor map that gets you to the right aisle quickly, at the small risk that the best match sits one aisle over.

Reach for it when

Search by meaning: “how do I get my money back” should find the page titled “Refund policy”
Retrieval for LLM apps (RAG): fetch the few chunks of your own documents most relevant to a question
Recommendations and deduplication: “more like this”, similar images, near-duplicate products
Combining similarity with filters such as tenant, language or date over millions of items

Think twice when

Exact matches on ids, names or part numbers; a B-tree or a keyword search index does that better and cheaper
A few thousand vectors: a brute-force scan in your database or in NumPy is exact and fast enough
You need perfect recall from an approximate index; results change slightly once an index is added
The data already lives in PostgreSQL or a search engine that supports vectors; a separate store adds a sync job

A real example

A help centre splits its articles into 1 million chunks and embeds each as 768 32-bit floats: 1,000,000 × 768 × 4 bytes, about 3 GB of vectors. A question is embedded the same way, and an HNSW index returns the 5 nearest chunks for the chatbot to quote. The catch is filtering: with pgvector’s default ef_search of 40 and a lang = 'en' filter that matches 10% of rows, the index finds about 4 matching rows on average, fewer than the 5 asked for. Iterative index scans (pgvector 0.8.0 and later) or a partial index per language fix that.

Technologies

Specific products, and what each does differently.

ChromaOpen sourceAn open-source vector database for AI apps that runs inside a Python or JavaScript process, as a single server, or as a distributed service on object storage.

PineconeCommercialA managed, serverless vector database that keeps its indexes in object storage and serves dense-vector, sparse-vector and BM25 full-text search from the same index.

VectorizeCommercialCloudflare’s serverless vector database for Workers, which stores embeddings in R2-backed indexes and bills only for vector dimensions stored and queried.


Chroma	Open source	Chroma	Apache 2.0; Chroma Cloud is a paid hosted service	2026-10-09
Pinecone	Commercial product	Pinecone Systems, Inc.	Proprietary; managed service	2026-10-12
Vectorize	Commercial product	Cloudflare, Inc.	Proprietary	2026-10-12

What each provider calls it

AWS: Amazon S3 Vectors (vector buckets and vector indexes); Amazon OpenSearch Service k-NN search; pgvector on Amazon Aurora PostgreSQL and RDS for PostgreSQL
Google Cloud: Vector Search in Gemini Enterprise Agent Platform (formerly Vertex AI Vector Search, built on Google’s ScaNN algorithm) and Agent Retrieval (formerly Vector Search 2.0); AlloyDB for PostgreSQL with ScaNN, HNSW and IVF indexes; BigQuery `VECTOR_SEARCH` with IVF vector indexes; pgvector on Cloud SQL for PostgreSQL
Azure: Azure AI Search (exhaustive KNN or HNSW, with filters); Azure Cosmos DB for NoSQL with DiskANN vector indexes; pgvector on Azure Database for PostgreSQL
Open source & others: pgvector for PostgreSQL; Chroma; Elasticsearch and OpenSearch (`dense_vector` and `knn_vector` fields on HNSW); Faiss (MIT), Meta’s vector search library; Milvus, Qdrant and Weaviate, dedicated vector databases; LanceDB, an embedded retrieval library

In code · sql

CREATE EXTENSION vector;  -- pgvector

CREATE TABLE docs (
  id        bigint PRIMARY KEY,
  lang      text,
  body      text,
  embedding vector(3)  -- real models output hundreds of dimensions; pgvector indexes up to 2,000
);

INSERT INTO docs VALUES
  (1, 'en', 'Refunds take 5 days',   '[0.9, 0.1, 0.0]'),
  (2, 'en', 'We ship in 2 days',     '[0.1, 0.9, 0.1]'),
  (3, 'de', 'Return within 30 days', '[0.8, 0.2, 0.1]');

-- approximate index: an HNSW graph over cosine distance
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- the 2 English docs nearest to the question’s embedding
SELECT id, body, round((embedding <=> '[0.85, 0.15, 0.05]')::numeric, 3) AS distance
FROM docs
WHERE lang = 'en'
ORDER BY embedding <=> '[0.85, 0.15, 0.05]'
LIMIT 2;

--  id |        body         | distance
-- ----+---------------------+----------
--   1 | Refunds take 5 days |    0.004
--   2 | We ship in 2 days   |    0.714

Often confused with

Search indexes Relational databases Document databases Database indexes

Where it came from2013–2024

Finding the nearest points to a query is an old problem, and the classic answers, such as trees that split space with hyperplanes, work in a few dimensions but, as the Faiss authors put it, “do not scale well for dimensions above 10”. The problem became urgent when neural networks started turning data into embeddings. In 2013 Tomas Mikolov and colleagues showed word vectors learned from 1.6 billion words in less than a day, and embeddings are now made from words, text, images, and users and items for recommendation. Search by meaning then became a search for nearby vectors in hundreds of dimensions.

Two index families came out of research. Inverted files cluster vectors and scan only the nearest clusters, often with compressed codes; Facebook AI Research built them into Faiss and open-sourced it in March 2017, alongside a GPU paper that built a k-nearest-neighbour graph over 1 billion vectors in under 12 hours on four GPUs. Graph indexes went the other way: in 2016 Yury Malkov and Dmitry Yashunin described HNSW, a layered “small world” graph that gives logarithmic search and is similar in spirit to a skip list.

Large language models turned this into a database category. Retrieval-augmented generation needs to fetch relevant chunks of private data at query time, and in April 2023 Chroma raised $18 million to build an open-source database for exactly that. Existing databases answered quickly: pgvector, a PostgreSQL extension first released in April 2021, added HNSW in August 2023, and search engines, data warehouses and cloud object storage added vector indexes of their own.

Why it’s built this way

Approximate instead of exact search: Exact search compares the query with every stored vector, which is fine for thousands and too slow for millions. ANN indexes accept slightly lower recall, tunable at query time, in return for reading only a small part of the data.
Clusters (IVF) or graphs (HNSW): Graphs give the best speed for a given recall when memory is plentiful, typically below 1 million vectors per the Faiss authors. Beyond 10 million, graph build time becomes the limit, and compressed IVF indexes are the option when vectors don’t fit in memory.
Choose the distance metric with the model: Each embedding model suits particular metrics (Chroma’s embedding functions each declare the spaces they support). Cosine distance ignores vector length and inner product doesn’t, and in pgvector an index is built for one operator class, such as vector_cosine_ops, so it only speeds up queries using that distance.
Filter before or after the vector search: Metadata-first narrows to a small subset and searches it exactly; vector-first searches the index and drops non-matching results, which is fast but can return too few rows. The right choice depends on how many rows the filter keeps.

Timeline

2013
Mikolov and colleagues publish word2vec-style word vectors
2016
Malkov and Yashunin describe the HNSW graph index
2017
Facebook AI Research open-sources Faiss in March
2021
pgvector, a PostgreSQL extension, is first released in April
2023
Chroma raises an $18M seed in April; pgvector adds HNSW in August
2024
pgvector 0.8.0 adds iterative index scans for filtered queries

Sources24

Improve this page on GitHub